PerSignalConfig dataclass for StandardReadable devices to be used with a common implementation of prepare.

[burkeds]

This is one way prepare can be used in a standard fashion across StandardReadables while preserving the benefits of type-hinting.

PerSignalConfig is a dict-like dataclass which will take device signals as a key and a value. This dataclass is then passed to prepare and the signals will be set accordingly. Type checkers should recognize if a value not matching the signal type is assigned.

Example usage:

class MyMotor(StandardReadable):
    velocity: SignalRW[float]
    accl: SignalRW[float]

    def __init__(self, name: str = ""):
        super().__init__(name=name)
        with self.add_children_as_readables(ConfigSignal):
            self.velocity = SignalRW(name="velocity",
                                     backend=SoftSignalBackend(datatype=float,
                                                               initial_value=0.0))
            self.accl = SignalRW(name="accl",
                                 backend=SoftSignalBackend(datatype=float,
                                                           initial_value=0.0))


async def main():
    async with DeviceCollector(mock=True):
        device = MyMotor()
    config = PerSignalConfig()
    config[device.velocity] = 1.0 # Pyright throws a type-error if this is a str or something
    config[device.accl] = 2.0
    await device.prepare(config)
    print(await device.velocity.read())
    print(await device.accl.read())
    print("Finished")

if __name__ == "__main__":
    asyncio.run(main())


# OUTPUT
{'device-velocity': {'value': 1.0, 'timestamp': 6675122.751791038, 'alarm_severity': 0}}
{'device-accl': {'value': 2.0, 'timestamp': 6675122.752000068, 'alarm_severity': 0}}
Finished

[callumforrester]

This looks interesting and mirrors the behaviour of StandardDetector quite well. I've left some comments to stimulate discussion in the call later.

[callumforrester]

When we started on ophyd-async, a concern we had both with ophyd and pymalcolm was the large inheritance hierarchies that had developed over time. It was sometimes hard to reason about how a device would behave because the components of its behaviour were scattered across its parents in a non-obvious way. That's why Device is very sparse and even StandardReadble is still quite sparse, sometimes explicitness is better even at the cost of some duplication. We should be careful about introducing new default functionality at the parent level.

The alternative is to say that there is deliberately no default, generic functionality at the parent level and devices must implement their own, specific functionality.

[callumforrester]

What does this give us over a custom plan? I.e. this means we can type

yield from prepare(my_readable, ReadableDeviceConfig(foo=1, bar=2))
yield from read(my_readable)

instead of

yield from mv(my_readable.foo, 1, my_readable.bar, 2)
yield from read(my_readable)

But does it cover any other use cases?

[burkeds]

I was motivated to do this because there is no obvious way to configure a device. In StandardReadable there is no method that can use the configure protocol. It looks like prepare was intended to be a way to configure a device but there is no obvious way to use it. prepare only takes a single argument, intended to be a dataclass, so this is one way a dataclass might be used to write to any of the configuration signals using prepare.

To me, it does not at all seem intuitive to "move" a config signal to some value to set it. I suspect a typical user or beamline scientist might perceive this as "hacky".

One nice application of these dataclasses is that it provides a data structure for configurations one may use to swap configurations easily within a plan or save/load configurations to and from a file or database.

[burkeds]

@coretl Looks like there is a new linting error regarding an incompatible override of the epics motor with prepare. How do you think we should handle this?

[coretl]

@coretl Looks like there is a new linting error regarding an incompatible override of the epics motor with prepare. How do you think we should handle this?

Does making FlyMotorConfig inherit from PerSignalConfig fix the issue?

[burkeds]

@coretl Looks like there is a new linting error regarding an incompatible override of the epics motor with prepare. How do you think we should handle this?

Does making FlyMotorConfig inherit from PerSignalConfig fix the issue?

It does not because the attributes of FlyMotorConfig are not SignalW. For this approach to work, any variables required by prepare might need to be soft signals. What do you think?

[coretl]

After the collab call, are we still convinced we need this, or can it be replaced by load/save?

[burkeds]

After the collab call, are we still convinced we need this, or can it be replaced by load/save?

I think we can shelve this now. Config via load/save and abs_set seems fine.