Triggered Modify Action Not Staying on Path

RapidCode API
1

[RMP 10.4.3]

I am probing, which means that when an input goes high, a user limit commands an axis to perform a triggered modify. Each axis has a (nearly identical) user limit that uses the input as the trigger.

It is my understanding that the triggered modify action will decelerate but keep all axes in the motion group upon the same (linear) trajectory when the action takes place.

[Triggered Modify Action]

I am commanding a “probe move” that involves real movement on two axes in the MultiAxis. My expectation is that the motors will continue to move along the same line after the input trigger activates.

However, if I plot actual/command positions for this scenario, I’m not seeing what I expect.

My analysis captures firmware data for the two axes, and I then plot them against one another.

image
image1402×866 46.5 KB

The horizontal red line is the place (vertical axis) where the input triggers. The black line is the actual path that I’m commanding. The axes in the plot are scaled so that the numbers represent real-world units rather than motor counts. I’m sending waypoints via MultiAxis::MovePT(...).

(The motion buffer has a “size” 75 “ms,” though the “lag” in cmd vs actual won’t really be discernable in this type of plot.)

Here’s a close-up of the portion of the move that seems wrong to me.

image
image850×663 40.7 KB

Are my expectations incorrect? I would have expected both lines to be much closer to the superimposed black dashed line (expected path). I suppose my first guess is that the horizontal axis was decelerating too “fast” (or, the vertical axis too “slow”).

2

Hi @todd_mm,

TriggeredModify and EStopModify are based on the deceleration of each axis. The associated event takes the configured deceleration which is considered a safe rate to bring the associated axis to rest. Stop and EStop, on the other hand, use feedrate and a time value to bring the axis to rest by stepping rate of execution. These would maintain the path while bringing things to rest. In the case of Stop, you could Resume the motion if you so chose.

3

So, I thought I remembered modify being described as staying on path. I can’t find any docs to prove that assertion, so I guess I was incorrect.

If I wanted it to stay on path, would I need to choose deceleration values commensurate (and with the appropriate ratio) bring the motors to a halt (with respect to user units) at the same rate?

4

What is the use case for the modify actions? Is it just being able to control the magnitude of the resulting commanded deceleration?

5

Hi @todd_mm,

The main use case for the modify actions is using a set deceleration rate to stop as quickly as safely possible. If you get a Stop event at very slow speed, you still take the full StopTime to come to rest. You also need to make sure that your StopTime is sufficiently long enough to safety come to rest at your fastest possible speed.