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.
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.
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
(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.
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”).