You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 Hyperion refactor: Add lowest level FGS plan #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.
The text was updated successfully, but these errors were encountered:
olliesilvester
changed the title
Get bluesky on MX beamlimes
Get bluesky on MX beanlines
Jun 6, 2024
olliesilvester
changed the title
Get bluesky on MX beanlines
Get bluesky on MX beamlines
Jun 6, 2024
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 thatrestart_hyperion
worksGet 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 Hyperion refactor: Add lowest level FGS plan #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.
The text was updated successfully, but these errors were encountered: