Document strategies of waiting for a signal to match a value, pushing it down to EPICS or checking in the device or plan

[DominicOram]

As a developer I would expect set on a SignalRW to only finish when the readback of the signal matches the setpoint. This would, I think match the behaviour of ophyd.

[coretl]

I'm a little reluctant to push this down to the Signal level unless there is nowhere else to put it. I would prefer it was handled in one of two places:

• In the EPICS layer with put complete returning when the operation was complete, like we did for the valve and positioner templates
• In the Device level where thresholds can more easily be read, like we did for the motor record

Ideally we use put complete to work out when it stopped, then additional checks at the device level if we need to check the readback matches the setpoint, optionally within a tolerance. If there is no put complete, then this could be put in the Device level too.

How would this look for your use case?

[DominicOram]

This particular use-case is setting BL03I-MO-ROBOT-01:NEXT_PIN and reading BL03I-MO-ROBOT-01:NEXT_PIN_RBV. These are integers so no need to worry about tolerance. I have currently solved it by putting the check in the device, which is working fine. I'm happy for it to be in the put complete of the PV, I can discuss this with MX controls if you think it's the best solution?

[DominicOram]

I just found https://github.com/bluesky/ophyd-async/blob/febf9ceab0744a4699ad5d208f7b737cb3b7376d/src/ophyd_async/core/signal.py#L536, which I could use for this. I think putting the put callback in is good too though

[coretl]

Co-opting this ticket to turn into some documentation on the strategies of waiting for a signal to match a value, pushing it down to EPICS or checking in the device or plan