[RMP 10.4.3] (We’ll be upgrading soon, though this behavior is probably the same.)
Multiple Coordinated Motion Groups
I am attempting to run multiple motion coordinated motion groups at once. I have, say, two MultiAxis objects, each containing a mutually exclusive list of axes. I am attempting to command motion on each of them via MovePT(...)
(just like I do when there’s only one coordinated motion group).
Probing, using User Limits with Output Capture and Actions
Now, I’m attempting to probe on each of these motion groups simultaneously and independently. This means that I have a user limit for each axis that captures the position when a particular input goes high. For each MultiAxis, one of the user limits also has an E-Stop action.
The Problem
When I probe with only one of these motion groups at a time, things work fine.
However, when I probe with both of these two motion groups simultaneously, things work not-so-fine. I get a lot of halting motion that shouldn’t be there. I captured the positions and velocities for some of the axes involved, and it looks as if there are infrequent occurrences of adjacent positions that are identical (i.e. velocity is zero) in the middle of an ordinary (nonzero velocity) move.
Identifying the Culprit
It is difficult to prove exactly who is at fault here because I don’t currently have a means of saving every scrap of data that runs through the process. Here are some likely culprits.
- the motion/trajectory planner
- If this were the culprit, I would expect some of these errors to occur when I only probed with one motion group.
- The trajectory planners for each motion group are isolated (mostly, as far as I can prove) and do not care what the other is doing.
- the interlocutor between the trajectory planner and RMP
- There’s room for error here because I maintain this code.
- It seems unlikely that I would re-send a single point (as opposed to re-sending a batch of points) because I usually send a burst of points at a time.
- If I were doing something like this, I would expect it to be as a result of
MovePT()
failing or being in a state when it would fail if I called it.
- If I were doing something like this, I would expect it to be as a result of
- RMP
- This is the component I have the least knowledge of.
- There could very well be some config/setup that I’m doing incorrectly.
- The only way to prove (to me) that it’s RMP is to prove that it isn’t the other two.
Patterns of Behavior
I captured a bunch of data in the firmware (using recorders) hoping to find patterns in the circumstances when I see these Single-Instance-Zero-Velocity commands. Axis0 is in one motion group. Axis3 is in another.
These two graphs illustrate what seems like a strong pattern. Look for these features.
- The commanded velocity (“Vel/Accel”) will have occasional blips to zero (solid, light red/blue lines).
- The blue lines are instances when Axis3 halts. The solid red lines are when Axis0 halts.
- When the user limit fires and the axis is commanded to a stop by RMP, the axis firmware (“MultiAxis.FW”) status bits seem to indicate it.
- The dashed lines indicate when the input (that triggers the user limit) activates.
Now, notice that when there’s motion blip for one axis, if you look at the corresponding red/blue line in the axis firmware status for the other axis, the other axis is almost always reacting to a user limit (e-stop) action. (I’m sorry; the plots are very busy, but I’ve attempted to distill the information down to what we might need for further discussion.)
Is the Gun responsible or the person holding the gun?
My first question is: Am I supposed to do anything special to prevent this kind of behavior?
I mean, is this behavior what you’d expect, given certain configuration/setup? Is there something I could be doing that would cause a user limit action targeting axes in one motion group to affect axes in a different motion group? (BTW, I also captured the MultiAxis firmware status, and it looks nearly identical to the Axis firmware status.)
You guys sometimes inform me of setup steps that I didn’t do when I want non-default behavior, so I guess I’m asking if there is any such setting that would affect this that already is in my power to control?