Create a device for XPRESS3 AreaDetector

[stan-dot]

For SWIFT / i20-1 beamline for the initial tests with bluesky and blueapi.

Acceptance Criteria

• Have the device runnable with plans from its directory

Steps

• check what are the CA channels used
• compare Java implementation - there are many of them, also for fluoresencence. many for many different beamlines
• compare Pilatus https://github.com/bluesky/ophyd-async/blob/main/src/ophyd_async/epics/areadetector/pilatus.py
• check main methods from ophyd-async

[DominicOram]

There is already an xpress3 mini, which has a very similar interface, in https://github.com/DiamondLightSource/dodal/tree/main/src/dodal/devices/xspress3_mini. Could we replace what's there with an ophyd_async one?

[stan-dot]

looked into it, sounds very feasible

[Relm-Arrowny]

As far as we can tell xspress3 has more channels and that is about it. For book keeping mini and standard datasheet can be find here:
Mini
xspress3

[Relm-Arrowny]

I had a quick stab at making xpress3 mini, there are two, three things I am not sure about and need to get back to it:

1. what is ArmingSignal(Signal) for?
2. what is the best way to replace arm_status.wait inside arm and self.arm in stage as AsyncStatus does not have wait like Status:

  def arm(self) -> Status:
        LOGGER.info("Arming Xspress3Mini detector...")
        self.trigger_mode_mini.put(TriggerMode.BURST.value)
        arm_status = await_value_in_list(self.detector_state, self.detector_busy_states)
        self.erase.put(EraseState.ERASE.value)
        arm_status &= self.acquire.set(AcquireState.ACQUIRE.value)
        arm_status.wait(self.ARM_STATUS_WAIT)
        return await_value(self.acquire, 0)

3. I also could not locate the ERASE signal in express3 epic pv so I am not sure what it does, I am guessing it clear the busy state?
4. Is there some example plan where it is use? I am quite confuse with the arm_status as it wait for the busy status for the detector.

Current state will probably work but it does not wait correctly.

[DominicOram]

1. what is ArmingSignal(Signal) for?

Arming the detector takes time therefore we would like to do it asynchronously in the plan. At the time of writing the previous code you could not run stage asynchronously so the workaround was create a signal you could set to high then wait on that set to finish. I believe you could now just replace all of the arm with stage and remove the ArmingSignal.

2. what is the best way to replace arm_status.wait inside arm and self.arm in stage as AsyncStatus does not have wait like Status:

Basically in ophyd_async anywhere you see a signal.wait you can replace it with an await so:

        arm_status &= self.acquire.set(AcquireState.ACQUIRE.value)
        arm_status.wait(self.ARM_STATUS_WAIT)

just becomes:

await self.acquire.put(AcquireState.ACQUIRE.value)

3. I also could not locate the ERASE signal in express3 epic pv so I am not sure what it does, I am guessing it clear the busy state?

I think the PV exists for xspress3 too:

$ caget BL20I-EA-DET-06:ERASE
BL20I-EA-DET-06:ERASE          

I'm not 100% sure what it does, the reason we set it is probably because we just copied what GDA does when arming, we should understand it and document it though. Best to talk to more spectroscopy people or maybe controls? @iain-hall?

4. Is there some example plan where it is use? I am quite confuse with the arm_status as it wait for the busy status for the detector.

Yep, see https://github.com/DiamondLightSource/hyperion/blob/main/src/hyperion/experiment_plans/optimise_attenuation_plan.py

Current state will probably work but it does not wait correctly.

Great, do you have a branch?

[Relm-Arrowny]

Great, do you have a branch?
yes, https://github.com/DiamondLightSource/dodal/tree/473-create-a-device-for-xpress3-areadetector

[stan-dot]

Pls make a draft PR

[stan-dot]

we need more details on how is xpress3 used at i20-1

[Relm-Arrowny]

This is currently at the point where it can replace express and express mini with only signal and triggering functionally, we need to bring interested party to find out how express will be use.
The other issue is we have no hardware to test and I kind of know I10 is getting one in the next few months. So this is currently on ice.

[DominicOram]

The other issue is we have no hardware to test and I kind of know I10 is getting one in the next few months. So this is currently on ice.

What exactly would you like to test? I can find some testing time on i03 probably

[stan-dot]

@Relm-Arrowny we could add another issue for i10 to do later and merge this just for the devices that are out there now, like i03

[Relm-Arrowny]

I think the bottle neck for this is probably gathering use case for the extra functionally.

The other issue is we have no hardware to test and I kind of know I10 is getting one in the next few months. So this is currently on ice.

What exactly would you like to test? I can find some testing time on i03 probably

As for test, for now the only untested part is the triggering, I was more thinking if this is not needed now, I can have an express3 that I can play with extensively in a few month time.

[Relm-Arrowny]

@Relm-Arrowny we could add another issue for i10 to do later and merge this just for the devices that are out there now, like i03

That is possible, but it wouldn't really add anything to the exiting xpress mini other than changing it to ophyd-aysnc.

[DominicOram]

That is possible, but it wouldn't really add anything to the exiting xpress mini other than changing it to ophyd-aysnc.

This is valuable in itself. I would suggest we get your PR merged with the goal just being to ensure behaviour is the same and then we can look at wider usecases later.

As for test, for now the only untested part is the triggering, I was more thinking if this is not needed now, I can have an express3 that I can play with extensively in a few month time.

Ok, once your PR is merged I can test on i03 that it still all works as before, would you like to come down for the test?

[Relm-Arrowny]

That is possible, but it wouldn't really add anything to the exiting xpress mini other than changing it to ophyd-aysnc.

This is valuable in itself. I would suggest we get your PR merged with the goal just being to ensure behaviour is the same and then we can look at wider usecases later.

As for test, for now the only untested part is the triggering, I was more thinking if this is not needed now, I can have an express3 that I can play with extensively in a few month time.

Ok, once your PR is merged I can test on i03 that it still all works as before, would you like to come down for the test?

Okie, let me clean up the draft PR. I would love to see the test if it is convenient, if nothing else I would like to see how it done and may be ask some question.