How costly (in terms of performance) is it to call Axis::EStopTimeSet()? How frequently could I call it without ill effects?
The down side to using E-Stop as an action is that I cannot configure stop parameters in terms of motor/machine capability, though in general, I want to stop “as soon as possible” (e.g. for safety reasons). I have to choose/calculate a quantity of seconds over which to apply the action. For some moves, this would be OK (though still far less desirable than a decel-based action). For others, I want to stop just as fast as is reasonable, which is based on the current velocity at the moment when the action should start and the motor’s max decel.
I don’t want to set ridiculously small times, because then I jeopardize the mechanics of the machine (when larger inertias are in play).
If I wanted to “stream” e-stop times based on the commanded velocities, how frequently could I do it without any worry of ill effects? I realize that I still have the problem of delayed execution between sending a point and the motor actually executing it to wrestle with. This is sort of an academic question concerning how I might be able to use E-Stop to my advantage if I really had to.
Is there a good way to continuously change the e-stop time so that it is essentially decel-based?
I see you are trying to get the time based E-Stop to behave like a deceleration based E-Stop. We have our senior engineers working on the bug you found. Please be patient with us while we get trigger modify working for you. I would recommend waiting for the fixed version of trigger modify.
If you are determined to try this I would recommend only changing the EStopTime if the axis velocity has changed by a significant percent so that you aren’t calling it every loop.
E-Stop is not intended to have its time changed during execution of an EStop.
Thanks, @nikolas. I am trying to work around the potential problems with the *Modify actions, though I’m not trying to set E-Stop times just before E-Stop-ing. I’m trying to achieve something like sensible E-Stop times that are a function of motor capability rather than an arbitrary time values (which are only going to be good for a range of feed rates).
The problem I have is that my (portion of the) app doesn’t exactly know what the target feed rate is (I only know instantaneous feed rates), so I will need to periodically recalculate E-Stop time in order to get reasonable behavior (rather than stops that are entirely too slow or dangerously fast).
I don’t actually want to stream E-Stop times with the frequency that I send motion data via MovePT(). I just want to know how frequently I could update the E-Stop time without creating new problems.
Updating the E-Stop time in the way your are suggesting shouldn’t cause a problem. However as this is not the intended use we haven’t stress tested it for time and I can’t give you a hard number of a call frequency that would cause a problem at this time.
That is why I would recommend only changing the EStopTime if the axis velocity has changed by a significant amount. Each loop you could do a quick percent change calculation and only update the E-Stop time if say the feed rate has changed by 5%.
1 Like
“…this is not the intended use…”
Fair enough. I’m looking for recommendations, and you’ve done that. Thanks.
Even if it were only “safe” to set E-Stop times before we start sending motion points, that would be a useful recommendation (knowledge is useful, that particular requirement wouldn’t be useful to me), too.
Thanks for the reply, @nikolas.