Should STOP include a backlash correction?

[prjemian]

When a motor is in motion and a backlash would normally be taken at the end of the move, if STOP is set to 1, should the motion decelerate to a stop and then perform any backlash correction that applies?

This question arose from a discussion about the bluesky framework.

[kmpeters]

I have a few thoughts about this:

1. Setting STOP to 1 should NOT perform a backlash correction and the STOP field behavior should not be changed.
2. If there is a need for a graceful stop that does a backlash correction, a new field should be added.

When I stop a motor, I don't want it to continue to move. I'm usually stopping it because I need send it to a different position, so the backlash correction for the move that is aborted is irrelevant, because I'm going to let the next move succeed, which will do a backlash move, if necessary.

What is the use case for a graceful stop?

[prjemian]

I believe you are describing a different case, where a move-in-progress is retargeted. No backlash correction need be applied for exactly the reason you describe.

[prjemian]

from https://github.com/bluesky/bluesky/issues/1296:

For a given motor, what special cases are there that should prevent a controlled stop from applying appropriate backlash correction? The entire point of backlash correction is to leave the motion axis at a more predictable position after the move than if no backlash correction has been made.

[kmpeters]

I believe you are describing a different case, where a move-in-progress is retargeted. No backlash correction need be applied for exactly the reason you describe.

I'm arguing that a user sets STOP=1 when it is not desirable for the current move to complete, including the backlash correction. The user aborting the move should decide what happens next. I have seen the STOP field used to abort motion that would cause collisions and I believe that adding a backlash correction after stopping the motor would result in behavior that is counter-intuitive to users and be potentially unsafe.

(Edited to add a missing word)

[kmpeters]

from bluesky/bluesky#1296:

For a given motor, what special cases are there that should prevent a controlled stop from applying appropriate backlash correction? The entire point of backlash correction is to leave the motion axis at a more predictable position after the move than if no backlash correction has been made.

I would argue that it doesn't make sense for a motor to continue moving after a user has told it to stop.

[MarkRivers]

The entire point of backlash correction is to leave the motion axis at a more predictable position after the move than if no backlash correction has been made.

Telling a motor to stop while it is moving will always leave it at an unpredictable position!

I agree with @kmpeters. The Stop command is often used in a panic situation and we want it to stop ASAP.

[anjohnson]

If bluesky wants a motor to stop with backlash correction at roughly the current position, couldn't it just send a new demand to move to the latest known value of its current position, or to a projection of the position at some time in the future by which time it might be able to stop based on the current velocity?

[kmpeters]

If bluesky wants a motor to stop with backlash correction at roughly the current position, couldn't it just send a new demand to move to the latest known value of its current position, or to a projection of the position at some time in the future by which time it might be able to stop based on the current velocity?

Yes. That should work if the NTM field is YES, which is the default setting.

[prjemian]

I believe this question has been answered. Thanks, all.