You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
I was working with an Ophyd device of type PVPositionerIsClose, and I noticed a strange behavior when the setpoint is already at the desired position. In this situation, the device gets stuck because the setpoint or readback callbacks are never triggered (assuming the device setpoint will never oscillate).
This issue is particularly problematic in a common use case: setting a positioner to a specific position and starting a relscan from that position. If I start the relscan with a value of 0, it gets stuck indefinitely.
Proposed Discussion
I was wondering if we could bypass/trigger the PVPositioner callback in this case, but maintaining the core logic of the positioner for the self.done.
Related Discussion
I came across this related issue: #402. While the problem described there is somewhat different, it was an interesting discussion that inspired me to consider this approach.
Steps to Reproduce
Use a PVPositionerIsClose device with a setpoint already at the desired position.
Attempt to start a relscan beginning at a position of 0.
Observe that the device gets stuck indefinitely without triggering the setpoint or readback callbacks.
Let me know your thoughts or if there’s another recommended approach to address this.
The text was updated successfully, but these errors were encountered:
Possibly the simplest would be to extend _setup_move in PVPositionerComparator to call _update_setpoint. I'm somewhat second-guessing my previous decision to subscribe to the setpoint signal at all, it would probably be cleaner and more consistent to only call _update_setpoint during move or set.
Description
I was working with an Ophyd device of type PVPositionerIsClose, and I noticed a strange behavior when the setpoint is already at the desired position. In this situation, the device gets stuck because the setpoint or readback callbacks are never triggered (assuming the device setpoint will never oscillate).
This issue is particularly problematic in a common use case: setting a positioner to a specific position and starting a relscan from that position. If I start the relscan with a value of 0, it gets stuck indefinitely.
Proposed Discussion
I was wondering if we could bypass/trigger the PVPositioner callback in this case, but maintaining the core logic of the positioner for the
self.done
.Related Discussion
I came across this related issue: #402. While the problem described there is somewhat different, it was an interesting discussion that inspired me to consider this approach.
Steps to Reproduce
Use a PVPositionerIsClose device with a setpoint already at the desired position.
Attempt to start a relscan beginning at a position of 0.
Observe that the device gets stuck indefinitely without triggering the setpoint or readback callbacks.
Let me know your thoughts or if there’s another recommended approach to address this.
The text was updated successfully, but these errors were encountered: