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
This issue begins moving Hyperion's plans into a more generic form inside this repo, see DiamondLightSource/hyperion#1067. The idea is to decompose Hyperion bluesky plans into common building blocks for any MX beamline to use. A beamline can then construct its specific implementation by building up these smaller generic plans. We should also look into using bluesky's 'prepare' command for device setup.
To kick off , I think it makes sense for the first plan added to be the lowest level plan for the fast grid scan. Since it is the lowest level, we need to make sure that this plan is as generic as possible, and that any beamline wanting to do a fast grid scan can use this base plan. It should have similar functionality to do_fgs() in hyperion's flyscan_xray_centre_plan.py. Its parameters should be:
A list of devices. We should work out which devices are essential for this plan (is it just the FGS motor?), and leave room for optional devices (like zocalo).
A generic 'device setup plan' (which could look like a two level plan, one to specify each individual device setup and one to specify the order/waiting requirements)
A generic 'device tidy plan', to be used if there is an exception during the plan, or, optionally, at the end of the plan
The plan should:
Set up all devices as specified in parameters and wait appropriately
kick off the FGS
Optionally wait for any optional devices (like zocalo)
do a bps.complete()
Do any tidy-up
Be in a try block so tidy-up happens on an exception
EDIT: This is like a plan stub, so is not designed to be ran by itself. Therefore, this plan shouldn't consider setup or tidy-up
The text was updated successfully, but these errors were encountered:
This design sounds good as-is. A few possibilities for discussion:
Since the aim here is to create building blocks, I think it's okay if they are not self-contained i.e. if it doesn't make sense to run them on their own. So you could take out the exception handling and expect that to be handled separately. Different users may just compose it in different ways e.g.
You could, of course, also provide the two plans above for convenience, but I think it's good to have a pattern of different compositions rather than lots of if statements in a plan. I fear if-heavy plans will get bloated as more and more cases are added.
I think there may also be scope for handling the optional devices separately, perhaps as a group that you then pass into do_fgs()? I'm not sure because I don't know exactly how they are set up and tied into the fgs operation.
I agree with looking into the prepare command to remove complexity, I might even suggest doing that as part of this exercise.
This issue begins moving Hyperion's plans into a more generic form inside this repo, see DiamondLightSource/hyperion#1067. The idea is to decompose Hyperion bluesky plans into common building blocks for any MX beamline to use. A beamline can then construct its specific implementation by building up these smaller generic plans. We should also look into using bluesky's 'prepare' command for device setup.
To kick off , I think it makes sense for the first plan added to be the lowest level plan for the fast grid scan. Since it is the lowest level, we need to make sure that this plan is as generic as possible, and that any beamline wanting to do a fast grid scan can use this base plan. It should have similar functionality to
do_fgs()
in hyperion'sflyscan_xray_centre_plan.py
. Its parameters should be:(is it just the FGS motor?), and leave room for optional devices (like zocalo).A generic 'device setup plan' (which could look like a two level plan, one to specify each individual device setup and one to specify the order/waiting requirements)A generic 'device tidy plan', to be used if there is an exception during the plan, or, optionally, at the end of the planThe plan should:
Set up all devices as specified in parameters and wait appropriatelybps.complete()
Do any tidy-upBe in a try block so tidy-up happens on an exceptionEDIT: This is like a plan stub, so is not designed to be ran by itself. Therefore, this plan shouldn't consider setup or tidy-up
The text was updated successfully, but these errors were encountered: