When I call set on a Motor from a plan it has the behaviour that it will not return until the motor reaches its setpoint. This logic is mostly inherent to the EPICS motor record. This behaviour is very useful from a plan as it easily allows us to set motions asynchronously and wait on them to complete at a later time. However, for most other devices e.g a temperature controller, this logic is not in EPICS. It would be useful to have some helper functions that let us put this in ophyd-async to make these devices look like motors.
Notes:
- We will need some tolerance to know if we get to the setpoint
- Like the motor the device should just behave like a plain signal when read from (e.g. read as
device.temp rather than device.temp.readback
- We already have
epics_signal_rw_rbv which ties signals together but doesn't provide the set logic. We need to make it clear the difference between these and when they should be used. The api for both these things should probably be similar and they should reference each other in some way with guidance on how to use them
Potential solution:
class SetpointReadback(Moveable[T]):
def __init__(self, setpoint_pv:str, readback_pv:str):
self.setpoint = soft_signal_w(T, setpoint_pv)
self.readback_pv = soft_signal_r(T, readback_pv)
self.tolerance = soft_signal_rw(T)
async def set(self, value: T):
await set_and_wait_for_other_value(self.setpoint, value, self.readback, lambda x: ...)
Acceptance Criteria
- There is a generic setpoint/readback device that ties logic together
- This is well documented
When I call
seton aMotorfrom a plan it has the behaviour that it will not return until the motor reaches its setpoint. This logic is mostly inherent to the EPICS motor record. This behaviour is very useful from a plan as it easily allows us to set motions asynchronously and wait on them to complete at a later time. However, for most other devices e.g a temperature controller, this logic is not in EPICS. It would be useful to have some helper functions that let us put this inophyd-asyncto make these devices look like motors.Notes:
device.temprather thandevice.temp.readbackepics_signal_rw_rbvwhich ties signals together but doesn't provide the set logic. We need to make it clear the difference between these and when they should be used. The api for both these things should probably be similar and they should reference each other in some way with guidance on how to use themPotential solution:
Acceptance Criteria