Update to ophyd-async 0.17a4

[gkalua]

WIP

OOO until 1/4/26

Downstream changes for mx-bluesky:

• Update mx bluesky for ophyd async 0.17 mx-bluesky#1752

[shihab-dls]

I'm going to make a new release of ophyd-async soon, that includes changes to OdinIO, necessary to fix some existing bugs, but also includes quality of life changes that may reduce the number of operations we do in the configure_arm_trigger_and_disarm_detector plan. Let's block this until I've released the changes, then I will pick up converting the the plan and related test.

[DominicOram]

I've tested a bunch of beamlines dodal connects to see if this change breaks beamlines

Thanks @oliwenmandiamond! It's expected that the PVI's cannot connect remotely as they use PVA and there is currently no PVA gateway on that allows us to read them remotely. We can test them fully by running dodal connect on the beamlines however, it is worrying that the PVI pvs now seem wrong e.g. pva://BL19I-EA-EIGER-01:PVI is obviously more correct than BL19IPVI, which I think does need looking into.

Actually, this doesn't seem possible because the API of NDArrayBaseIO and ADBaseIO has changed between versions. Thoughts on how to resolve?

I think for the tetramms we can just change it back. For i11 it looks like the enum on BL11I-EA-DET-07:DET:DetectorState_RBV doesn't match that on the latest version of ADCore, I will discuss with controls.

[EmsArnold]

b01_1
fails connect (every device a part from synchrotron)
Note: Still connection errors without this change, so not related from what I can tell

Just checked this on the beamline, we're connecting to everything that we expect to connect to (imaging_detector is physically unplugged at the moment, and we've not been able to connect to the synchrotron for a while on the beamline - a separate issue).

[DominicOram]

I think for the tetramms we can just change it back.

It's not quite that easy. After more investigation I think the underlying issue is that we're using https://github.com/epics-modules/quadEM/tree/master for controlling the tetramms. This doesn't inherit from ADDriver but instead from asynNDArrayDriver. I think there may also be a number of other problems such as the comment in the old driver saying:

        # tetramm never goes idle really, actually it is always acquiring
        # so need to wait for the capture to finish instead

but we're using ADArmLogic now, which does wait for the state to go to idle. Generally probably needs more thought and testing on the beamline

[DominicOram]

This is such a big review I think we're going to have to break it up. For now I've put off the mythen issue and then:

• @DominicOram and @jacob720 to check the Eiger is ok
• @DominicOram to check the tetramm is ok
• @oliwenmandiamond are you happy that the electron analyser is still ok?
• @Relm-Arrowny are you happy that the ScreenCam is ok?
• @rtuck99 and @JamesOHeaDLS this PR also replaces the commissioning Jungfrau that was using @ndevenish's writer with the one using the odin writer. Is this ok?

[JamesOHeaDLS]

The Odin for Jungfrau is not ready yet, so it needs to keep using Nick's writer

[oliwenmandiamond]

@DominicOram am happy with the electron analyser bits. I will need to fix them though as gone out of date now

[DominicOram]

The Odin for Jungfrau is not ready yet, so it needs to keep using Nick's writer

Then does someone in @DiamondLightSource/developers-mx-daq have capacity to update the commissioning JF to the new version?

[DominicOram]

I have confirmed that dodal connect passes (or has no change in errors). Found #2061 in the process but it's unrelated.

[DominicOram]

I'm happy that this now works for my beamlines. I have tested on i15-1 and will test on i22 tomorrow. If I see errors on i22 I'll make new PRs

[oliwenmandiamond]

@DominicOram @CoePaul @rtuck99 @jacob720 @Relm-Arrowny

Can CommissioningJungfrauDetector (dodal/devices/beamline/i24/commissioning_jungfrau.py) be deleted? It has no tests associated with it and is not being used by any beamline.

SingleTriggerDetector also has no tests. These are used by p99 and i10. Is someone able to write some tests for them?

[DominicOram]

Can CommissioningJungfrauDetector (dodal/devices/beamline/i24/commissioning_jungfrau.py) be deleted? It has no tests associated with it and is not being used by any beamline.

As per James' comment above we can't remove it and it is being used by i24. I will write some tests.

SingleTriggerDetector also has no tests. These are used by p99 and i10. Is someone able to write some tests for them?

Sure, I will do this too