Implement Async Position Restoration for Movable via Database

[stan-dot]

Currently, Movables do not have the capability to restore their position from an asynchronous database. We could use a feature that allows a Movable object to fetch and restore its position from an async database. This functionality could be implemented via a decorator or a new interface method. Additionally, the position restoration should support caching, ensuring that the most recent 'set' call is recorded and used when restoring the position.

This decorator / interface could be persistence-mechanism-specific, for instance RedisCacheable interface or 'cache_with_redis(redis_client_instance)'.

Discussed with @Relm-Arrowny

Stakeholders:
Users of ophyd-async who require Movables to restore positions after reboots or for devices that lack an encoder

Business Case:

Allowing Movables to restore their position from an async database would provide more robust state persistence across system restarts and long-running operations, improving reliability and automation for users with complex systems requiring position tracking.

Acceptance Criteria:

• - Async Position Retrieval: Movable should be able to asynchronously fetch its last known position from the database when requested.
• - Caching: Each time a Movable’s position is updated (via a 'set' call), the new position should be cached to ensure quick access on future restores.
• - Position Restoration: After a system restart or disconnection, Movables should automatically restore their position from the database, ensuring consistency with the last set position.
• - Interface/Decorator: The solution should either introduce a decorator or a new interface method to manage async database interaction for Movables.
• - Test Coverage: The feature should include unit and integration tests to verify proper behavior, including caching, position retrieval, and restoration.

[coretl]

Unless I misunderstood this, autosave already does this at the EPICS layer. Why do we need to do this at the ophyd level?

[stan-dot]

ah right, it's not for 'every' position but only for the 'good' positions.

to be able to revert back to a state. tbh that could go with a plan 'set motors x, y, z ' to position A/B/C where a plan causes a multi-dimensional move.

@Relm-Arrowny thoughts?

[jwlodek]

Presumably you could also use load_device with an input being a settings object with the positions you want to send the motors to?

[coretl]

ah right, it's not for 'every' position but only for the 'good' positions.

to be able to revert back to a state. tbh that could go with a plan 'set motors x, y, z ' to position A/B/C where a plan causes a multi-dimensional move.

@Relm-Arrowny thoughts?

From the description above it is not clear whether you want:

• To keep track of where the motor is, then if the motor controller is rebooted restore this position without having to home the motor. This is what autosave does, and I would caution that it is generally less robust than rehoming as the axis might have drifted while the motor controller was offline
• To keep track of where the motor last moved, then be able to restore to "where all the motors were at a particular point". For this I would either use load/save if you know when you are at a known good position, or the EPICS archiver if you want to go back to an arbitrary point in time

[Relm-Arrowny]

ah right, it's not for 'every' position but only for the 'good' positions.

to be able to revert back to a state. tbh that could go with a plan 'set motors x, y, z ' to position A/B/C where a plan causes a multi-dimensional move.

@Relm-Arrowny thoughts?

I am not sure.... I thought we were talking about a data base where we can write and retrieve data related to the motion/experiment, e.g. look up table for the ID/mono, UB matrix setting, etc...Things that do not live in the motor record but are used to drive motor/devices. Data that are useful after restarting/starting bluesky. Is this better describe what we want? @stan-dot

[stan-dot]

yeah I agree

[coretl]

So this is then about storing and fetching matrices and lookup tables rather than actual positions? This doesn't sound like writing to hardware, so I question whether it lives in ophyd-async.