Expose `MRES` in the EpicsMotor

[DominicOram]

It is useful to get the MRES out of a motor to give you a tolerance to work out if the motor is at the position you want it to be.

[prjemian]

In such cases, I subclass and add the desired signals. Since these are not needed for every motor, even most motors, I choose not to expose them to ophyd, last they become misused.

…

On Tue, Aug 1, 2023, 7:37 AM Dominic Oram ***@***.***> wrote: We have a couple of usecases where it's useful to get these values out of the motor: - ACCL is useful in calculating triggering timings - MRES is useful to be able to work out if a motor has been left in the position we want it in It would be good if these are exposed at the EpicsMotor layer — Reply to this email directly, view it on GitHub <#1141>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMUMDWYATRRZXDS7EYTTTXTD2BTANCNFSM6AAAAAA27WKBNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DominicOram]

Yh, that's the solution I currently have but I didn't really like it as I would probably end up using it so much in my codebase that EpicsMotorWithMRES becomes more of a standard than EpicsMotor. I actually think being able to ask a motor for its tolerance is quite a universal thing. To clarify, I would put this in as read-only, setting resolutions is definitely not something we should be doing.

[prjemian]

Having bluesky/ophyd know the tolerance or step size of a motor is less universal than I originally imagined. Like <5% of an instrument's axes from the various instruments I see at the APS.

There are already lots of signals (EPICS PVs) connected for an EpicsMotor. What is one more, you might ask? One might also ask where does one draw the line at the "one more" question (such as for ACCL or VBAS)? I'm still thinking this is not in such broad use that it should be made for all.

So here's the evil example which I use with a soft IOC that simulates a working beamline. The default SREV of 200 is just too small for my examples and test cases, so I change it:

class MyEpicsMotor(EpicsMotor):
    steps_per_revolution = Component(EpicsSignal, ".SREV", kind="omitted")


m1 = MyEpicsMotor(f"{IOC}m1", name="m1", labels=("motor",))
m2 = MyEpicsMotor(f"{IOC}m2", name="m2", labels=("motor",))
m3 = MyEpicsMotor(f"{IOC}m3", name="m3", labels=("motor",))
m4 = MyEpicsMotor(f"{IOC}m4", name="m4", labels=("motor",))

m1.wait_for_connection()
m1.steps_per_revolution.put(2000)

[prjemian]

The time-to-velocity is exactly the example for why MRES is needed. But you also need ACCL and VBAS to properly compute the time it takes to reach VELO, and to compute the time required for a move. Also need BDST, VBAS (maybe others) if end-of-move backlash correction is a concern (usually not for fly scans).

[DominicOram]

So a lot of the PVs you mention are also needed for #1122. Some of them, such as ACCL are actually already there. To answer your question about where does one draw the line with another question; what is the overhead for adding more Signals? I'm not sure there is any significant overhead computationally or in code complexity?

[prjemian]

I believe the only addition to latency is that it adds another EPICS PV search and connection and then ophyd Signal creation. All these seem inconsequential. Adding MRES does not change the probability of connection success since these fields are common to the EPICS motor record and should be connectable if the RBV and VAL fields connect. (Which might fail if someone is replicating the IOC without using EPICS base. Odd edge case, that one.)

FWIW, I'm not opposed to the addition, it's useful. Especially as EpicsSignalRO. If someone really wants to change the MRES from ophyd, that special case can subclass.