bluesky / ophyd-async

Hardware abstraction for bluesky written using asyncio
https://blueskyproject.io/ophyd-async
BSD 3-Clause "New" or "Revised" License
7 stars 21 forks source link

Require units for signals and motors #362

Closed callumforrester closed 1 month ago

callumforrester commented 1 month ago

As a developer I would like to specify that a motor or signal should work with a particular unit and have connection fail if the control system gives a different value, for example:

class MyDevice(StandardReadable):
    def __init__(self, name: str = ""):
        self.foo = Motor("X", units="mm")
        self.bar = epics_signal_r("TEMP", float, units="celsius") 
        super.__init__(name)

It would help to mitigate the circumstance of having similar hardware but different units.

Acceptance Criteria

  1. The example given fails to connect if the units from epics are wrong, even if the data types and PV names are correct.
DiamondJoseph commented 1 month ago

Why would someone be writing a device that cares about a particular unit (m vs. mm?) So long as the signal propagates what the units are.

callumforrester commented 1 month ago

Say I have a device that controls a motor that is used on one beamline in µm and a plan that controls it and says "move to 12000", but then someone copy/pastes the same device and same plan and runs it, not knowing that on their beamline the PVs are similar but the motor works in mm. It will be hard to diagnose why epics raises an alarm and the plan fails, until they notice that the plan tried to move their motor 12 meters away.

DiamondJoseph commented 1 month ago

So we'd be guaranteeing that all devices of type D are in the same units? But presumably beamlines A&B have their D in different units on purpose (different use cases), and now there's 2 versions of D.

It'd be good if a plan/mv/set could take units and convert....

callumforrester commented 1 month ago

I think it's reasonable to retire this issue until a clear use case comes along