New Action: Stop(deceleration), Stay on Path

How difficult would it be to add an action, similar to E_STOP or TRIGGERED that would

  • use motor deceleration for position calculations
  • stay on path

In order for this to work, it would have to use all the motors in a MultiAxis (if the axis is in one). (Is any part of this already in existence for other actions?)

We’re trying to stop during a coordinated move, but using a stop time for this means that I have to do the math relating to the coordinated move and calculate a stop time that works for the slowest moving motor (though I only have planned motion to work with, rather than current/actual velocities).

Is there a better way to do this?

Hey @todd_mm

Hmm, I’m not sure a deceleration based event would stay on the path. What about directly issuing FeedrateSet in a manner that matches your desired profile for pausing on the path? This involves a lot of heavy handling in your application currently, but sounds like it might work well as a “future” RtTask.

How is a standard Stop event failing you when you pre-plan a stop time appropriate for your fasting moving axis?

So, the catch is that I want a coordinated deceleration across all the axes in a multi axis.
All motion (in my application) configured by the user based on max velocity and acceleration parameters.

Calculating the correct time requires knowing the instantaneous velocity, and that is something that I can’t really know when I’m planning things 70ms in advance. (This particular scenario is a probe move that will stop when an input activates and won’t execute the rest of the motion.)

I don’t know when the stop action will happen, and so doing time-based calculations (during planning) means that if it’s happening during an accel/decel, the stop will be slower than it could/should be.

However, the motion controller knows instantaneous velocities and positions and could calculate a stop using decel parameters by discerning how much time it would take for each motor in a motion group to stop and using the stop time from the “slowest” motor. I imagine that the motion controller could do a much better job that I can, since I can only make calculations based on the maximum commanded velocity (which may never even be achieved).

The ultimate goal is to make the system the most responsive to the input triggering and the stop happen as quickly as the user has configured maximum acceleration/deceleration.