Skip to content

Create a helper to easily allow tying a setpoint and readback together #996

Description

@DominicOram

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions