Speaker
Description
Mature solutions exist for direct control of synchrotron beamline hardware; many advanced use cases now depend on automation and parallelisation. However, these features come with higher complexity and risk: race conditions may cause collisions, wrongly interpreted data, or other errors.
Building on existing tooling which allows spawning Beamline Experiment Control (BEC) clients within isolated scripts, we developed a system for responding to changes in beamline conditions with arbitrary actions executed on a BEC client. The system has access to any information in the BEC message broker as input for its conditions. This architecture allows consistent validation and safety checks.
Our goal is that simple automation tasks should be easy, while complex tasks are possible and assembled from modular combinations of simpler tasks. Envisaged uses include pausing scans when beam is lost and restarting them when it is restored and sending messages to external services (e.g. MS Teams) when chosen signals reach defined values. These can be chosen by beamline staff through configuration changes.
At the other end of the spectrum, actions can include triggering a centring routine when a sample is loaded, or data collection when a sample is centred. Combining all of the above leads to a fully automated experimental workflow, responding dynamically to beam conditions, and notifying users of any errors through direct messages.
