Add missing signals to SimMotor and create Motor Protocol

[oliwenmandiamond]

When using a motor in plans for testing and live, we want to specify a motor device but don't care about underlying implementation. At the moment, we're having to extend SimMotor to add missing signals and then use type: ignore when used in test plans. We should do the following things:

• Add the following missing signals to SimMotor

def __init__(
    self,
    ...
    low_limit: float = float("-inf"),
    high_limit: float = float("inf"),
    max_velocity: float = 100,
    ...
):
    ...
    self.max_velocity = soft_signal_rw(float, max_velocity
    self.low_limit_travel = soft_signal_rw(float, low_limit)
    self.high_limit_travel = soft_signal_rw(float, high_limit)
   ...

• Create a Motor protocol which defines the the base signals a device needs to define so that any device or plan can specify Motor protocol so it doesn't matter if a SimMotor or epics Motor
• Possibly rename Motor to EpicsMotor?

Acceptance Criteria

• Generic interface for Motor for plans and devices created so it doesn't matter on underlying implementation

[jwlodek]

I suggest if we rename Motor, to use AsyncEpicsMotor (and maybe AsyncSimMotor, since those same class names are used in ophyd v1. Would be good to make them easily distinguishable.

[oliwenmandiamond]

I would say make a protocol AsyncEpicsMotor and then have EpicsMotor and SimMotor (rename to SimEpicsMotor?) implement it. This way, I can provide my plan and / or device and it doesn't matter if it's live or sim. I don't see the point in distinguishing between SimMotor and Motor as the point of this is to make that a plan or device it doesn't matter if Sim or Live, I just declare the type as AsyncEpicsMotor

[coretl]

I'm inclined to go the opposite direction:

• Remove from SimMotor anything that is not directly related to the simplest possible simulated motor, and make the signals intentionally different from epics.Motor to differentiate them
• Make a more useful mock mode for epics.Motor to allow you to test your plan (refs Provide the ability to inject logic when mock devices are created #1039)

What extra mock behaviour would you need to make testing plans easier?

[oliwenmandiamond]

At the moment, we are checking the upper and lower limits of a motor in some of our plans. This doesn't work when using a SimMotor as it doesn't define low_limit_travel and high_limit_travel so we have to extend SimMotor to add those signals and then either

Initialise a SimMotorExtra as fixture in test
A: then when given to plan we type:ignore
B: but when we use this in our test we say it is a Motor to get around type checking (I find this confusing when reading code as you're declaring something that it isn't)
C: and adjust plan signature to allow Motor | SimMotorExtra

Please see DiamondLightSource/sm-bluesky#208

My solution is to create a Motor interface via Protocol which sim and epics implement, then plan and tests work by using interface

[oliwenmandiamond]

I'm hesitant in extending Motor with additional logic to account for mock mode as then we're overloading the device to account for too many conditions. A simple interface help separate this logic.

However, if we had a way to inject the logic of SimMotor into Motor, that could also work but seems convoluted and possibly confusing for this problem

[coretl]

Having thought about this more, I'm even more convinced that #1039 is the answer. I will make pitch a solution to it over there...