Open DiamondJoseph opened 6 days ago
You are correct, there are no units there: https://github.com/areaDetector/ADCore/blob/1a9135976b4bc75bfdfe1ed7516a3e7d29e08e6b/ADApp/Db/ADBase.template#L173-L207
However changing these would break all our screens which do not leave space for a units field!
They are always seconds at the moment...
Maybe we can add a kwarg that is basically acquire time scale factor, defaulting to 1. Then we assume that the input is always in seconds, and the scale factor can adjust the number based on the device needs if for whatever reason it is not one.
I'd prefer it to just be handled in the existing standard way, how viable is changing our screens?
I'd prefer it to just be handled in the existing standard way, how viable is changing our screens?
3 year time scales...
We could put a workaround in ophyd-async that overrides the EGU in an EpicsSignalBackend
until then?
So long as it ends up passed through the signal metadata
This needs:
epics_signal_r
, epics_signal_rw
, epics_signal_rw_rbv
to take optional units
and precision
like soft_signal_rw
:
https://github.com/bluesky/ophyd-async/blob/8a18c3bc39a2d5f85daf5c1951447d076ec8be6d/src/ophyd_async/core/signal.py#L295-L309metadata
to CaSignalBackend
and PvaSignalBackend
__init__
, and pass them through to converter.get_datakey
like SoftSignalBackend
:
https://github.com/bluesky/ophyd-async/blob/8a18c3bc39a2d5f85daf5c1951447d076ec8be6d/src/ophyd_async/core/soft_signal_backend.py#L185-L186units="s"
to acquire_period
and acquire_time
:
https://github.com/bluesky/ophyd-async/blob/8a18c3bc39a2d5f85daf5c1951447d076ec8be6d/src/ophyd_async/epics/areadetector/drivers/ad_base.py#L47-L48
Presumably this is part of the areadetector implementation?
Acquire time could be measured in seconds, milliseconds etc. and knowing which is crucial.