Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add do fgs_plan #140

Merged
merged 27 commits into from
Oct 30, 2024
Merged

Add do fgs_plan #140

merged 27 commits into from
Oct 30, 2024

Conversation

olliesilvester
Copy link
Contributor

@olliesilvester olliesilvester commented Aug 5, 2024

Fixes #80 as part of https://github.com/orgs/DiamondLightSource/projects/6/views/1?pane=issue&itemId=73047222. This adds a slightly modified version of the do_fgs plan in Hyperion. Here, you can optionally device whether or not we need to do extra things - eg zocalo. This plan should be usable for VMXm, i03, i04, and hopefully other MX beamlines.

The idea of the level 1 folder is for it to be filled with plan stubs, i.e plans that cannot be ran on their own. I guess it could just be renamed to plan_stubs... I renamed it plan_stubs

To test:

Copy link
Contributor

@dperl-dls dperl-dls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we will probably want another level of categorisation than this, maybe put do_fgs into a gridscan module?

Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I think we can maybe keep them even more similar

src/mx_bluesky/plan_stubs/do_fgs.py Outdated Show resolved Hide resolved
Comment on lines 46 to 47
if post_plans:
yield from post_plans()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: Similar to above, I think we might be able to:

  1. Wait for the zocalo stage in hyperion before calling do_fgs
  2. Just always read the devices we have in both plans

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the wait for zocalo stage has the potential to take 2 seconds. I think maybe for the moment keep the post_plans bit and call it with a wait for stage on hyperion. I think it should be renamed to during_collection_plans though, as that's what it is

Copy link

codecov bot commented Oct 14, 2024

Codecov Report

Attention: Patch coverage is 98.78049% with 1 line in your changes missing coverage. Please review.

Project coverage is 78.39%. Comparing base (afcde5b) to head (72677d5).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #140      +/-   ##
==========================================
+ Coverage   78.28%   78.39%   +0.11%     
==========================================
  Files          93       96       +3     
  Lines        6815     6850      +35     
==========================================
+ Hits         5335     5370      +35     
  Misses       1480     1480              
Components Coverage Δ
i24 SSX 57.08% <ø> (ø)
hyperion 96.65% <100.00%> (+0.17%) ⬆️
other 93.99% <98.64%> (-1.82%) ⬇️

Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to put comments on this again. Is there a reason we didn't just put all of kickoff_and_complete_gridscan in common? I think it is common to all beamlines?

@olliesilvester
Copy link
Contributor Author

Sorry to put comments on this again. Is there a reason we didn't just put all of kickoff_and_complete_gridscan in common? I think it is common to all beamlines?

No real reason, I was just trying to move bits incrementally, and wasn't sure about the Zocalo bits on other beamlines

@DominicOram
Copy link
Contributor

DominicOram commented Oct 22, 2024

Sorry to put comments on this again. Is there a reason we didn't just put all of kickoff_and_complete_gridscan in common? I think it is common to all beamlines?

No real reason, I was just trying to move bits incrementally, and wasn't sure about the Zocalo bits on other beamlines

I agree about the zocalo stuff not being needed everywhere but I think the other decorators are common, and would be needed for nexus/ispyb writing. If you want to do that in the next PR though that's fine

@olliesilvester
Copy link
Contributor Author

olliesilvester commented Oct 22, 2024

OK, I'll put the whole function in common, minus some Zocalo bits

@olliesilvester
Copy link
Contributor Author

I started to reshuffle some of the hyperion tests in test_flyscan_xray_centre to the common test_do_fgs, but this quickly led into me having to move the whole parameter model + all callbacks into common too, so that is a job for a separate ticket

Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of final questions around the tests but generally there.

tests/unit_tests/common/plan_stubs/test_do_fgs.py Outdated Show resolved Hide resolved
Comment on lines 53 to 57
"mx_bluesky.common.plans.do_fgs.check_topup_and_wait_if_necessary"
) as mock_check_topup,
patch(
"mx_bluesky.common.plans.do_fgs.read_hardware_for_zocalo"
) as mock_read_hardware,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Why not have these as a patch decorator? Seems slightly cleaner?

assert len(null_messages) == 0


def test_kickoff_and_complete_gridscan_with_run_engine_correct_documents(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could: It's probably better to test this with the real zocalo callback. Otherwise we end up potentially going down the rabbithole of #479

Copy link
Contributor Author

@olliesilvester olliesilvester Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, agreed. I did start to do this, but then it lead to having to move the callbacks to common, which requires also moving the parameters + constants to common, so I reverted. Anyway, I'll add a comment linking to an issue, saying to change this test once the zocalo callbacks have been moved

tests/unit_tests/common/plan_stubs/test_do_fgs.py Outdated Show resolved Hide resolved
Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thank you!

@DominicOram DominicOram merged commit 4b4fdba into main Oct 30, 2024
22 checks passed
@DominicOram DominicOram deleted the 80_add_do_fgs_plan branch October 30, 2024 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hyperion refactor: Add lowest level FGS plan
3 participants