Optionally use fastcs eiger for XRC

[jacob720]

Fixes #1076

Requires bluesky/ophyd-async#1127 and DiamondLightSource/dodal#1706

Instructions to reviewer on how to test:

1. Do thing x
2. Confirm thing y happens

Checks for reviewer

• Would the PR title make sense to a user on a set of release notes

[DominicOram]

Thanks, some comments in code. When you test it I suspect you might get issues with not calling complete and instead calling unstage (at

mx-bluesky/src/mx_bluesky/common/experiment_plans/inner_plans/do_fgs.py

Line 106 in 76a7e48

else_plan=lambda: (yield from bps.unstage(detector, wait=True)),

). I think we just try that and see though

[DominicOram]

Must: Annoyingly I don't think this is going to work. The code in

mx-bluesky/src/mx_bluesky/common/utils/context.py

Line 45 in 8b6a2fc

def device_composite_from_context(context: BlueskyContext, dc: type[DT]) -> DT:

will populate the composite based on the parameter name being the same as the device name and the type being the same. I think you will instead need to have a new device in this composite called fastcs_eiger: FastEiger

[jacob720]

Ah ok, I wanted to avoid that for now as it would involve creating a fastcs eiger in the i04.py device factory, as the I04 XRC composite class inherits from FlyScanEssentialDevices. But maybe that isn't a problem, I've just created an I04 fastcs Eiger.

[DominicOram]

Yh, we will want to test on i04 at some point anyway

[DominicOram]

Should: is there a dodal PR needed? I can't see this in main

[jacob720]

Yeah, will update the PR
DiamondLightSource/dodal#1706

[DominicOram]

You want CONST.WAIT.GRID_READY_FOR_DC

[codecov]

Codecov Report

❌ Patch coverage is 89.65517% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.24%. Comparing base (97a841e) to head (ee0f35a).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1436      +/-   ##
==========================================
- Coverage   92.26%   92.24%   -0.03%     
==========================================
  Files         142      142              
  Lines        8031     8042      +11     
==========================================
+ Hits         7410     7418       +8     
- Misses        621      624       +3     

Components	Coverage Δ
i24 SSX	78.44% <ø> (ø)
hyperion	98.02% <100.00%> (-0.01%)	⬇️
other	97.99% <88.46%> (-0.09%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[olliesilvester]

Noticed a couple of things after briefly skimming

[olliesilvester]

I don't think we can actually use StandardDetector for the type here since we use dev_shm, which is specific to Odin. Maybe we can use StandardDetector[DetectorController, OdinWriter]

[jacob720]

That's good to know, could we just use FastCSEiger? How much more general is StandardDetector[DetectorController, OdinWriter] than FastCSEiger

[olliesilvester]

Well theoretically any standard detector which writes using odin could do the XRC plan, but I doubt we'll be doing this anytime soon. So yeah, can just use FastCSEiger for now

[olliesilvester]

The old eiger device waits for frames when we unstage. The fast-cs eiger will just immediately disarm on unstage.

For the fast-cs eiger we need to do yield from bps.complete instead - this will wait for frames with a default timeout, or the timeout specified in TriggerInfo

[DominicOram]

Good spot, thanks

[DominicOram]

Waiting on testing time