Open AdrianPotter opened 7 years ago
Depending on the OPI, especially for older ones, it may be considering a MOT:MTR0101 when it should be considering an axis instead, we should probably make sure that they are pointing at an axis. The Pinhole selector is giving MOT:MTR0605 as an example, if that axis on the galil was failing on backplate, then it could become MTR0707 – using an axis instead of the motor means we don’t need to change the synoptics as well as the axis definition in that situation. The Jaws are doing something similar. It looks as if there isn’t a full axis for the pinhole, just a LKUP – so the underlying behaviour may need updating to use an axis. The Jaws should be using JAWSn:d, where n is the ‘index’ of the Jaws/Slits, and d is the direction (North/South/East/West).
It may be that the axis aliasing isn’t complete enough to allow this, but I would not expect the client to need to be told which physical motor something was – only the axis it relates to. If the aliasing does not allow this (which I though it did) then we ought to ensure that it does. We can use the MTR0n0n format, but the purpose of the aliasing is that anything used by the client doesn’t need to be changed on hardware failure, only one place on the server needs to be altered.
At the moment, some motor-based OPIs use macros for motors that contain the
MOT
prefix (e.g.MOT:MTR0101
) but some don't (e.g.MTR0101
). Theopi_info.xml
file which records the macros has been updated as of ticket #1289 so the info file and the OPIs agree.As a user, I would like there to be a consistent use of motor PVs in OPIs.
The OPIs will need updating accordingly and update notes added to the release notes as this will be a breaking change.