DiamondLightSource / DiamondLightSource/mx-bluesky
Get bluesky on MX beamlines
- Dominant language
- Python
- Stars
- 4
- Forks
- 5
- Avg merge
- 1d 30m
- Merged PRs (30d)
- 2
Description
MX are going to start getting Bluesky, with BlueAPI, working on MX beamlines. I will start this work using VMXm, since they are already using Bluesky via Hyperion This is a parent issue with a list of the first big chunk of work which is required for all of this, roughly in the correct order:
- Create a deployment script for mx_bluesky + blueapi. We need further discussion here, but we should try and get kubernetes clusters for all MX beamlines next shutdown perioid, and deploy blueapi on a container. To start with, this can just work for VMXm, but it should be written in a way such that it works for other beamlines with minimal modification. In the end, we would like one deployment script which updates all mx beamlines at the same time. Extension: A beamline could keep a list of bluesky plans they use, and then the deploy script could tell us which beamlines will be affected by changes to plans.
- Add a `restart_blueapi` command to gda. For now, it will be useful to be able to restart blueapi via GDA, in the same way that `restart_hyperion` works
- Get a basic bluesky plan working via blueapi on VMXm. Once we have this, it can be the template for how it'll work in other cases.
- Work out how to generalise the FGS plan which Hyperion uses. This will involve looking i03's and vmxm's current implementations in detail, working out the differences, and thinking about all the generalisations we can make.
- Do https://github.com/DiamondLightSource/mx_bluesky/issues/80 . For incremental testing, I think it would be best to gradually replace Hyperion's bluesky plans with the generalised mx_bluesky plans, and deploy and test as much as we can.
Contributor guide
Assessment
This issue has not been assessed yet.