Speaker
Description
Bridging Sardana and Bluesky: Adopting the Bluesky Queue Server for Sardana Control
Sardana and Bluesky are two widely used control systems at synchrotron facilities, each with a large existing user base and macro/plan libraries. Bluesky provides a good way to orchestrate experiments using queue plans, and lets users manage and monitor those queues through the queue server. The queue server also offers an HTTP API with authentication and group-based roles, which improves both security and operational stability — users are confined to certain operations based on their group membership, while staff or beamline scientists can be granted elevated access for things like reordering, pausing, or aborting the queue. Sardana, despite being mature and widely deployed, currently lacks all of these features: there is no built-in remote HTTP API, no authentication layer, and no concept of group-based access control for macro submission.
Rather than building a new queue management system from scratch to add these capabilities to Sardana, we chose to adopt the existing Bluesky queue server and adapt it to work with Sardana. This was done by replacing the queue server's usual RunEngine submission path with submission through the Sardana Door. Macros available on the Door are parsed and exposed to the queue server as allowed plans, and the devices/motors known to the Sardana pool are exposed as allowed devices. This means the queue server can validate and manage Sardana macro submissions the same way it would validate native Bluesky plans.
An additional benefit of this approach is that it standardizes the interface layer for other beamline software. Tools like Daiquiri, which sit on top of the queue server, don't need to know whether the underlying execution engine is Bluesky's RunEngine or Sardana's Door — they just talk to the queue server's API. That means the control backend can be swapped out later without changing anything on the client/UI side, since the API remains same.
