Accml proposal

[Sulimankhail]

You can find my presentation from 25 Jul 2025 here:
Pattern_Driven_Architecture_for_pyAml.pdf

Implementation Repository

The implementation is available in the accml repository on GitHub: https://github.com/python-accelerator-middle-layer/accml.

Invitation to Collaborate

I invite everyone to collaborate on this project. Contributions can take the form of co‑coding sessions or code reviews. I will add a todo list to the GitHub repository soon to coordinate work and highlight open tasks. Feel free to open issues or pull requests if you want to discuss ideas or contribute.

Current Status and Future Plans

At the moment there is an EPICS‑based example (a tune measurement script) that depends on the Bluesky and Ophyd libraries. We are actively working on a general measurement execution engine that will be independent of Bluesky and Ophyd, making the framework usable in non‑EPICS labs.

[TeresiaOlsson]

@Sulimankhail I'm wondering in your proposal if it's possible for the user to read and set devices without using the measurement execution engine? For example, I don't want to do a measurement but just read what the current value of a steerer is. Is there a way I can just run a get on a device without it being a plan run together with the measurement execution engine?

In ophyd this is possible. You can use the devices either directly if you want or together with the runengine depending on what you are doing. I think we also need this in pyAML so you can use devices in two ways:

• Directly if you just want to read and set things. Kind of like a control system agnostic version of pyepics/pytango where the user doesn't need to remember PV/attribute names because that's handled by the pyAML config.
• Together with a measurement execution engine when you are running measurement which require the full experiment orchestration with automatic metadata generation, error handling, saving to standardized format etc.