Support ophyd-async devices for DOFs

[mrakitin]

We need to test that blop can work with ophyd-async devices.

[thomashopkins32]

Definition of done:

• Create unit tests using ophyd-async devices
• Create tutorial using ophyd-async devices

If ophyd-async doesn't work out of the box (tests fail) then try to resolve issues.

[thomashopkins32]

So it looks like blop cannot currently support ophyd-async devices as DOFs or Objectives. This is because blop reads directly from ophyd signals using Signal.read(). However, blop does use bps.mv (a bluesky plan stub) to set new values.

There are a couple of options worth considering here to add ophyd-async support (in order of my personal preference):

1. Use scan instead of mv to set values and read back the results automatically (maybe with some configurable delay?). blop should not interface with ophyd or ophyd-async devices directly. All data should flow through bluesky first. This option could allow for easier bluesky-adaptive integration later as an added benefit. Finally, the current implementation of DOF.readback() suggests that there is probably a better way to do this: https://github.com/NSLS-II/blop/blob/main/src/blop/dofs.py#L304-L307

2. Figure out how to support both async and sync readbacks similar to how its implemented in bluesky. This seems to create a significant amount of overhead and could be duplicating work already done in bluesky. Is this simpler than it looks for blop?

3. Create a clear separation in the interface for ophyd and ophyd-async compatible blop agents.

What do you guys think? @NSLS-II/blop-team

---

Here is the context of my understanding of blop so far since I am still fairly new to the project:

blop only needs to be able to change the values of certain devices (i.e. motors, temperature controllers, etc.) and read back the result (from detectors, motors, temperature controllers, etc.) in order to run its optimization. Bayesian optimization should not require any interaction with ophyd (or ophyd-async) devices within a single iteration of its algorithm. Using a scan in place of the mv to set and read back results is my preferred option, however, if it could affect how bluesky's RunEngine handles callbacks (such as database I/O) then we may want to consider the alternatives.

[thomaswmorris]

In principle, every iteration of BO can be a scan. We could refactor the DOF to not have a device directly, and instead reference a device with a name.