Breaking Change: Rename and add motor fields

[DominicOram]

Fixes #42

Makes it easier to convert motors from ophyd to ophyd-async and will stop us having to do stuff like https://github.com/DiamondLightSource/dodal/blob/871e0526fa496e9b068eedd7d19c23027449cc26/src/dodal/devices/util/motor_utils.py#L5

Note that given the change in names it will break any current uses of the ophyd_async motor

To test:

• Confirm tests still pass

[Tom-Willemsen]

Calling MRES "max resolution" seems misleading - I'd rather call it motor_step_size. The resolution of the encoder position readback might be higher.

Do we also want ERES for encoder_step_size?

[DominicOram]

My bad, was a poor copy/paste, thanks.

I'm keen not to pre-emptively put in too much before we know we need it and Hyperion has yet to need ERES. I guess we could if we were trying to be more clever about tolerances on how close we are to things but we're not currently...

[coretl]

ERES defaults to MRES, so is actually the right thing to look at to work out encoder resolutions, RDBD is better to look for tolerances, as the motor record will treat this value as "how close to the readback do I need to be to be done", and I think it will ignore move requests within this deadband...

[DominicOram]

Is RDBD guaranteed to be set to non-zero?

[coretl]

No idea about guarantee, but a spot check of 3 motors showed that it seems to default to MRES unless overridden to be bigger

[DominicOram]

Ok, I'll change this to be RDBD and make an issue in dodal to switch

[DominicOram]

Ok, I've called it tolerance rather than RDBD as I think this makes more sense to a user of the device but happy to be argued with

[coretl]

Can we make it deadband instead? Sounds like tolerance to me, and closer to the EPICS name...

[DominicOram]

After discussion with @coretl about naming. We would like to match the ophyd names as much as possible to maintain compatibility. The ophyd names are:

    # position
    user_readback = Cpt(EpicsSignalRO, ".RBV", kind="hinted", auto_monitor=True)
    user_setpoint = Cpt(EpicsSignal, ".VAL", limits=True, auto_monitor=True)

    # calibration dial <-> user
    user_offset = Cpt(EpicsSignal, ".OFF", kind="config", auto_monitor=True)
    user_offset_dir = Cpt(EpicsSignal, ".DIR", kind="config", auto_monitor=True)
    offset_freeze_switch = Cpt(EpicsSignal, ".FOFF", kind="omitted", auto_monitor=True)
    set_use_switch = Cpt(EpicsSignal, ".SET", kind="omitted", auto_monitor=True)

    # configuration
    velocity = Cpt(EpicsSignal, ".VELO", kind="config", auto_monitor=True)
    acceleration = Cpt(EpicsSignal, ".ACCL", kind="config", auto_monitor=True)
    motor_egu = Cpt(EpicsSignal, ".EGU", kind="config", auto_monitor=True)

    # motor status
    motor_is_moving = Cpt(EpicsSignalRO, ".MOVN", kind="omitted", auto_monitor=True)
    motor_done_move = Cpt(EpicsSignalRO, ".DMOV", kind="omitted", auto_monitor=True)
    high_limit_switch = Cpt(EpicsSignalRO, ".HLS", kind="omitted", auto_monitor=True)
    low_limit_switch = Cpt(EpicsSignalRO, ".LLS", kind="omitted", auto_monitor=True)
    high_limit_travel = Cpt(EpicsSignal, ".HLM", kind="omitted", auto_monitor=True)
    low_limit_travel = Cpt(EpicsSignal, ".LLM", kind="omitted", auto_monitor=True)
    direction_of_travel = Cpt(EpicsSignal, ".TDIR", kind="omitted", auto_monitor=True)

    # commands
    motor_stop = Cpt(EpicsSignal, ".STOP", kind="omitted")
    home_forward = Cpt(EpicsSignal, ".HOMF", kind="omitted")
    home_reverse = Cpt(EpicsSignal, ".HOMR", kind="omitted")

[coretl]

Slight preference to call it acceleration_time over seconds_to_velocity or acceleration

[dperl-dls]

I think where the names are unclear/wrong (e.g. acceleration), this is our chance to change them...

[DominicOram]

I think where the names are unclear/wrong (e.g. acceleration), this is our chance to change them...

I think there is a balance where maintaining backwards compatibility is useful. I agree with the acceleration example though.

[Tom-Willemsen]

Was typing low_limit_travel, high_limit_travel and precision as int rather than float intentional?

[DominicOram]

Was typing low_limit_travel, high_limit_travel and precision as int rather than float intentional?

No, apologies, feel free to fix