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
As an MX DAQ developer we often have issues where we get confused about what units physical quantities are being expressed in (e.g. DiamondLightSource/mx-bluesky#220). It may be useful if we could be more strict about this in the code by leveraging something like pint. This would mean signals are set with Quantities that have units and will throw exceptions if the units given in the EGU field of the PV do not match. This is a spike to do the investigation on how hard this would be and what an interface would look like.
Acceptance Criteria
We investigate using a library like pint to allow setting signals with values that have unit metadata
We investigate how much this would change bluesky etc.
An estimate for the work is written up, with a mock up of roughly what the interface would look like on the plan/device side
It is decided whether we do this or not and an ADR is made
The text was updated successfully, but these errors were encountered:
As an MX DAQ developer we often have issues where we get confused about what units physical quantities are being expressed in (e.g. DiamondLightSource/mx-bluesky#220). It may be useful if we could be more strict about this in the code by leveraging something like pint. This would mean signals are set with
Quantities
that have units and will throw exceptions if the units given in theEGU
field of the PV do not match. This is a spike to do the investigation on how hard this would be and what an interface would look like.Acceptance Criteria
pint
to allow setting signals with values that have unit metadataThe text was updated successfully, but these errors were encountered: