bluesky: Alternative use of RE.halt() causes data to be marked incorrectly
RE.hault() is a great option to have, but the use case is more narrow than what is used in practice. If I get to the end of the measurement, I will use ^C to keep the motors where they are instead of waiting the 5 minutes for everything to go back to the initial conditions. I use halt to save time and not to just prevent a motor crash. In both of these cases, it doesn’t mean that the data was bad, it just means I needed (or preferred to stop but not return the motors to any position).
Is there any flexibility in re-thinking how the exit_status is labeled by RE.halt(). Or could we add an argument to RE.stop() to keep the motors in place? Perhaps this second option is nice because you could also add that argument to RE.abort() and just get rid of RE.halt()
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 16 (9 by maintainers)
If we
^Ca scan with bluesky and it finishes collecting point, it has not yet moved the motors again so it is in a “valid, known” position. To clean up the scan, we canRE.stop(), and the motors could return to the position prior to the scan. Stopping this motion will create problems for many of our motors.One motor we have, because of mechanical reasons, takes a very long time to travel, but if it starts to travel in the direction that needs the backlash, stopping it in CSS will put the sample outside of the beam (assuming small sample). The motor itself is good within 1 micron as long as backlash is used in the backlash direction.
Note that this is a motor the that uses the ophyd
EpicsMotorclass. I am not sure of the implementation of the epics IOC with the delta tau controller.