Community

MoveSCurve() Not (Quite) Getting to Position

RapidCode API
#1

[RMP 8.3.1]

I’m attempting to sync the positions of two slaved motors before sending motion data from our CNC motion planner (which assumes identical positions) to avoid jumps on enable.
I’m attempting to accomplish this using MoveSCurve().

Under some circumstances (I haven’t discovered a pattern), what I observe is that the axis moves, but never quite gets there (and stays in the MOVING state indefinitely—or until I run out of patience.

Here’s MotionScope data from the commanded move.

image
image1402×884 79.5 KB

Here’s a closeup of the “end” of the move.
image
image1402×884 69.1 KB

Here’s what RapidSetup shows during the never-ending move.
image

The axis is a part of a MultiAxis during this move (and, generally, always). Does that matter? None of the other axes are even enabled.

The command position is where I expect it to be. The motion parameters are sensible ( >> 0 ). Position error hovers around 1900 for as long as I want to wait (e.g. the entire time I spent composing this post).

Let’s assume I’m doing something to cause this behavior. What could it be? The axis has a state of MOVING, but it’s not actually changing position (more than just the normal flicker I see with these drives). What would keep it from attaining the command position without causing a fault or other error?

Ideas?

#2

I’ve also been playing with homing on these drives, though I don’t have a reason to suspect that to influence what I’m seeing.

#3

Also, if I break in my program just after MoveSCurve(), grow impatient waiting for the move to complete, abort, clear faults, enable, then command the s-curve move (all in RapidSetup), it gets there as one would expect.

#4

I’ve also noticed that after syncing positions between the master and slave (and ignore any errors), the slave drive will sometimes have a standing position error that never goes away. It moves when I command it (from our motion planner), but it never quite reaches the target position.

At this point, we’re just streaming motion data, and the positions between the two drives are identical (I can see that from the commanded position in RapidSetup). I just don’t know why the drive isn’t getting into position.

#5

Sounds like the Axis has not settled. What do you have set for all the settling criteria?

https://docs.roboticsys.com/rmp/topics/settling

If it doesn’t reach the target position, it is possible that the drive’s position loop is not using an integrator (or sufficient integrator) to result in zero position error (on the drive side).

#6

We’re using 200 for fine position tolerance, which is normally wayy above the kind of jitter I see in the drive position (0-10 PUUs). When it’s spinning, it’s a lot more than 200 PUUs away from the target.
I would assume that this is the reason why RMP is still MOVING, which makes sense.

The other part of my question is why isn’t the drive getting to position? Curiously, if I reconfigure our software to make the drive no longer a slave, it doesn’t behave this way: there’s no standing position error. This setting should have no effect whatsoever on the RSI::RapidCode::Axis object (it doesn’t result in other configuration API calls) except that its commanded position is identical to another axis.

Are there any data points I can look at as a means of comparison during “good behavior” and “bad behavior” times? If drive tuning is what we’re talking about, then I can look into that. I was mostly interested in things that I could be doing (probably unintentionally) that would keep the drive from actually reaching the target position.

#7

I would look at the raw network (Drive) values for position demand (command) and position actual, to see how those compare to the values in the RSI Axis. Take note of these values in the failing case, as well as the case after re-issuing the S-curve move from RapidSetup.

Since you mentioned drive-based homing, it is possible that the drive has adjusted internal positions by some drive origin position? (In this case it seems like it may be adjusting just command or actual, not both.)

The MultiAxis should not be an issue.

1 Like
#8

The drives I’m observing this behavior on are CTB. I haven’t tried with Yaskawa yet.
They do zero their reported encoder position on a (drive-based) home operation.
I don’t know if they have their own internal offset that they keep or not. (They probably do, but I have to connect with a serial/programming interface to see it.)

I’ll look at the PDOs for position the next time I see this behavior.
Thanks, Scott.

#9

In this occurrence, the slaved motors are “reversed” (e.g. motors on opposite sides of a gantry) so that, say, -100,000 for the master corresponds to +100,000 for the slave.

The PDO values correspond to what RMP/RapidSetup says the command (output) and actual (input) positions are.

The only difference that I can see is that bit #10 (0x400, “target reached”) of the status word is off on the slave drive (showing standing following error).

Motor#1 (Master)
  (!reversed)
  Input Position: 4294095929 (-871367‬) 0xFFF2B436
  Origin Position: 524287
  Output Position: 4294095926 (-871370) ‭0xFFF2B436‬
  Command Position: -1395657
  Actual Position:  -1395657
  Status Word: 5687 0x1637  (0001 0110 0011 0111)
    Ready To Swith On (0x1)
    Switched On (0x2)
    Operation Enabled (0x4)
    Voltage Enabled (0x10)
    Quick Stop (0x20)
    Remote (0x200)
    Target Reached (0x400)
    Operation Mode Specific (0x1000)

Motor#0 (Slave)
  (REVERSED)
  Input Position: 902218 0xDC448   (adj: 1393742)
  Origin Positon: -491524
  Output Position: 904133          (adj: 1395657)
   delta (cmd-actual): 1915
  Command Position: 1395657
  Actual Position:  1393745
  Status Word: 4663 0x1237
    Ready To Swith On (0x1)
    Switched On (0x2)
    Operation Enabled (0x4)
    Voltage Enabled (0x10)
    Quick Stop (0x20)
    Remote (0x200)
    Operation Mode Specific (0x1000)

I assume that “target reached” in the status word is a direct reply by the drive that it has not (yet) reached the commanded position, which is certainly an accurate statement.

I don’t know why, however.

1 Like