Bluesky compatibility

[TeresiaOlsson]

Figure out and evaluate options/requirements/consequences for Bluesky compatibility.

Current requirements:

• No mandatory dependencies in pyAML for any package in the Bluesky ecosystem.
• Be able to directly use the Bluesky runengine with pyAML devices for those labs which want this.

Current idea:

• Explore how pyAML devices could follow the interface provided by Bluesky https://blueskyproject.io/bluesky/main/hardware.html#hardware-interface.

[gubaidulinvadim]

Dear Teresia,

Since you are doing this exploratory task, could you write some bullet points on why Bluesky compatibility is necessary for you? What are the advantages of having it? I've never understood the motivation behind using the words "bluesky" so much. And I don't think I'm completely alone in his. So, it would be useful to have that written down somewhere.

[TeresiaOlsson]

I'm actually planning on doing more than that. I want to set up a chromaticity measurement so people can try themselves (and because we also need a new chromaticity measurement...) and see how they like the bluesky runengine, the automatic data management features that comes with it and what you can do when your measurement is running in streaming mode. The idea is to first develop it using ophyd-async for the hardware abstraction (since that currently is compatible with both TANGO and EPICS) just so people can test but if pyAML decides to include bluesky compatibility the idea is to later replace the ophyd-async devices with pyAML devices.

For HZB, it is important because we are one of the major contributors to bluesky (BNL and DLS are too) and we want to explore the possibilities that open up if accelerator, insertion device and beamline have devices that all can be used in the same measurement framework. Things like for example using the beamlines as advanced diagnostic beamlines for the machines, various timing modes (PPRE, TRIBs) where all levels need to work together etc. We currently have bluesky development going on both on the insertion device and beamline side and are planning to try to see if we can make a common undulator device that works for the measurements all of the levels need to do. For us it would be very sad if pyAML turns out to not be compatible with that work. For example, measuring feed-forward tables for the IDs are the responsibility of our ID group and they use bluesky and not MML for that.

But it will very likely take me a while until I reach the point where I have something to show.