Suggestion: New PV for identifying unit of measurement for 'Time' PVs

[jwlodek]

We have been using several cameras at some of our beamlines that run at vastly different speeds, and as such it may be convenient to be able to set the ExposureTime and AcquireTime PV values as different units than whatever is hard-coded in the driver (usually seconds).

I was wondering whether the following would be worthwhile: a new PV that holds the camera's time variable units (ex. s, ms, us). The default value would be 's', but a driver could override it. Then we could read this PV and display it next to the variables on the screen so that it is clear to the user what units they should be entering.

An example of where this would be useful is we have an Emergent Vision camera that doesn't allow setting the Exposure time to anything higher than 100 ms, and usually runs between 3-10 ms. Users have suggested that they would prefer to be able to write 3 or 10 rather than 0.003 or 0.01 for example.

I could work on this if it is deemed a worthwhile addition.

[prjemian]

Isn't that the .EGU field?

[MarkRivers]

Isn't that the .EGU field?

asyn device support currently has no way to send the value of the .EGU field to the driver. One would need to add a new stringout record that gets its value from the .EGU field and sends it to the driver.

One would probably not want to use the .EGU field because the user is likely to mess it up (ms, msec, MSEC). We probably want an mbbo with well-defined choices.

In areaDetector all time units are currently seconds, and the driver translates into whatever the device requires. I find this simpler because the user does not need to know that different detectors use different units.

One way to improve the user interface is to switch the OPI widget to engineering or exponential format. Then the user sees 1.0e-003 and if they want to change from 1 ms to 3 ms they just change the 1 to a 3 and they don't have some large number of leading zeros. I have used that format in other drivers (pulse generators, MCS units) where there is a large dynamic range in time.

What @jwlodek is proposing could be done. But it is a big job. New OPI screens are needed, new functions to do the translation in both directions, perhaps in the ADDriver base class.

[prjemian]

If an extra PV is added, could it's value be written to .EGU so the many client interfaces would not have to be changed?

[MarkRivers]

That can be done. Would there be just one TimeUnits PV that applies to AcquireTime, AcquireTime_RBV, AcquirePeriod, AcquirePeriod_RBV, and perhaps others? It would need to be copied to at least 4 .EGU fields.