Fastcs eiger support #528

DominicOram · 2024-08-19T15:43:04Z

See DiamondLightSource/dodal#700. This implements enough of the Eiger/Odin for us to prove that we can actually take some data with it. To completely cover all the capability of the ophyd device we need to do a lot, at least:

To Test

Confirm unit tests pass
Run the system tests as described in the system test directory, confirm they pass

Notes

I'm particularly interested in someone who knows the intent of the detector architecture to review this to confirm it follows the pattern correctly.

DominicOram · 2024-08-19T17:51:32Z

src/ophyd_async/epics/eiger/_odin_io.py

+            self._drv.data_type.set(
+                "uint16"
+            ),  # TODO: Get from eiger https://github.com/bluesky/ophyd-async/issues/529
+            # TODO: Where should I actually be setting this


I'm not sure on the best way to do this to best fit into the existing architecture

I'm not sure what "this" is? All the signal sets you mention seem to be in the right place, although I expected num_to_capture to be 0 so it would go forever...

Sorry, you're right that this is the number of frames. Ok, so the idea is that we will never run the file writer knowing how many frames it has up front? I think this will have side-effects that we're not used to for example that we will always have N files, where N is the number of processors, though most of the time some of them will be empty but this is probably ok.

callumforrester · 2024-08-20T07:59:39Z

system_tests/epics/eiger/start_iocs_and_run_tests.sh

+
+mkdir /tmp/opi
+
+podman run --rm -dt --net=host -v /tmp/opi/:/epics/opi ghcr.io/diamondlightsource/eiger-fastcs:0.1.0beta5 ioc $eiger_ioc


Could: Detect whether podman or docker are available and choose the command accordingly.

callumforrester · 2024-08-20T08:00:16Z

system_tests/epics/eiger/start_iocs_and_run_tests.sh

@gilesknap I wonder if this can be achieved with docker-compose or similar, so we can run it up either in the CI or locally in exactly the same way?

I didn't want to hold this up on the CI stuff, which could get fiddly so made #531

pyproject.toml

coretl · 2024-08-20T10:41:24Z

src/ophyd_async/epics/eiger/_eiger_controller.py

+        self._drv = driver
+
+    def get_deadtime(self, exposure: float) -> float:
+        return 0.0001


Where did you get this number from? If from the manual then please can you provide a reference?

coretl · 2024-08-20T11:34:41Z

src/ophyd_async/epics/eiger/_eiger_io.py

+class PhotonEnergy(Device):
+    """Changing photon energy takes some time so only do so if the current energy is
+    outside the tolerance."""
+
+    def __init__(self, prefix, tolerance=0.1, name: str = "") -> None:
+        self._photon_energy = epics_signal_rw_rbv(float, f"{prefix}PhotonEnergy")
+        self.tolerance = tolerance
+        super().__init__(name)
+
+    @AsyncStatus.wrap
+    async def set(self, value):
+        current_energy = await self._photon_energy.get_value()
+        if abs(current_energy - value) > self.tolerance:
+            await self._photon_energy.set(value)


Slightly concerned about putting this logic in the IO class. As written this will break load/save as it's not a Signal.

What's the use case for setting within a tolerance? If it's from a custom plan, could the logic be lifted into a plan stub? If not would a set_energy method on the detector be acceptable?

The use-case is that we want to avoid setting it as much as possible because it increases the time it takes to arm the detector and it's scientifically fine for it to be just within the tolerance. At the moment we bundle all the logic required to set up and arm the detector into a single bps.set because we need to do it all in parallel to another plan running. If we want to do this via plan_stubs then I guess we're blocked on bluesky/bluesky#1652. We could put it in a set_energy and call it during the arm

As discussed in person, we make a set_energy and put this in arm for now. May change when parallel plans is done

I have put it in prepare. I would rather put it in the arm so that we have a better ordering of when to do it but to do so would need to change the arm interface quite a bit, probably to take something that inherits from TriggerInfo. Are you happy for me to do this refactor?

@ZohebShaikh will be doing this as part of #405, so it would be useful if you could review and/or add to his PR to make sure the Eiger usecase is covered

coretl · 2024-08-20T11:57:00Z

src/ophyd_async/epics/eiger/_odin_io.py

As soon as PVI datastructures are published over PVA then this file will drastically change to something like:

class EigerDriverIO(Device): bit_depth: SignalR[int] stale_parameters: SignalR[bool] ...

It will also only need to include the signals that are needed at static analysis time, at runtime then all the extras (like beam_centre_x, etc) will be filled in automatically.

This will also mean that the class structure and ophyd attribute names will have to exactly match those in PVI.

For this reason I suggest we do this soon, and @GDYendell is going to start looking at this now

It will also only need to include the signals that are needed at static analysis time, at runtime then all the extras (like beam_centre_x, etc) will be filled in automatically.

Eventually all these signals will be needed at static analysis time. I have added in all the ones that we need to re-implement what we currently have on the ophyd eiger.

PVI structures will be added in DiamondLightSource/FastCS#54

coretl · 2024-08-20T11:58:13Z

src/ophyd_async/epics/eiger/_odin_io.py

+            self._drv.data_type.set(
+                "uint16"
+            ),  # TODO: Get from eiger https://github.com/bluesky/ophyd-async/issues/529
+            # TODO: Where should I actually be setting this


I'm not sure what "this" is? All the signal sets you mention seem to be in the right place, although I expected num_to_capture to be 0 so it would go forever...

coretl · 2024-09-02T09:14:15Z

src/ophyd_async/epics/eiger/_eiger.py

+
+    @AsyncStatus.wrap
+    async def prepare(self, value: EigerTriggerInfo) -> None:
+        await self._controller.set_energy(value.energy_ev)


After #405 then there will be a prepare method on the controller that takes a TriggerInfoT so this prepare method will become unnecessary. For now this is correct though.

DominicOram · 2024-09-02T13:29:19Z

Given the refactors in #405 and #551 I'm going to merge this as a MVP and park any further development on the other issues.

DominicOram added 4 commits August 15, 2024 14:19

Add PVs for fastcs eiger

d14f194

Add odin PVs

eca5850

Add ability to change photon energy

2c4d509

Add basic device and system test

aebc98c

This was referenced Aug 19, 2024

FastCS Eiger: Pass datatype from eiger to odin #529

Open

FastCS Eiger: Correctly implement describe and collect #530

Open

Add unit tests for eiger controller

0078df2

DominicOram mentioned this pull request Aug 19, 2024

FastCS Eiger: Put system tests in CI #531

Open

Add tests for odin

9df23f2

DominicOram mentioned this pull request Aug 19, 2024

FastCS Eiger: Allow setting the photon energy and other MX settings #532

Open

DominicOram commented Aug 19, 2024

View reviewed changes

DominicOram requested a review from DiamondJoseph August 19, 2024 17:52

DominicOram marked this pull request as ready for review August 19, 2024 17:52

DominicOram requested review from rtuck99, callumforrester, coretl, dperl-dls, olliesilvester and GDYendell August 19, 2024 17:53

callumforrester reviewed Aug 20, 2024

View reviewed changes

coretl reviewed Aug 20, 2024

View reviewed changes

DominicOram added 4 commits August 27, 2024 17:39

Clean up the containers after running them

c19ccca

Write files continuously and close odin on unstage

7c2d990

Allow specifying a photon energy during prepare

6574add

Add reference for deadtime

a650bbe

DominicOram requested a review from coretl August 27, 2024 22:06

coretl approved these changes Sep 2, 2024

View reviewed changes

coretl mentioned this pull request Sep 2, 2024

Eiger FastCS: Use PVI information to fill in PVs #551

Open

DominicOram added 2 commits September 2, 2024 14:21

Fix commented out running of container

76ad527

Merge branch 'main' into fastcs_eiger_support

ca69c77

DominicOram merged commit 372dd6d into main Sep 2, 2024
18 checks passed

DominicOram deleted the fastcs_eiger_support branch September 2, 2024 13:30

DominicOram mentioned this pull request Sep 2, 2024

Write an ophyd-async device against the fastcs eiger DiamondLightSource/dodal#700

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fastcs eiger support #528

Fastcs eiger support #528

DominicOram commented Aug 19, 2024 •

edited

Loading

DominicOram Aug 19, 2024

coretl Aug 20, 2024

DominicOram Aug 20, 2024

callumforrester Aug 20, 2024

callumforrester Aug 20, 2024

DominicOram Aug 20, 2024

coretl Aug 20, 2024

coretl Aug 20, 2024

DominicOram Aug 20, 2024

DominicOram Aug 20, 2024 •

edited

Loading

DominicOram Aug 27, 2024

coretl Sep 2, 2024

coretl Aug 20, 2024

DominicOram Aug 20, 2024

GDYendell Aug 22, 2024

coretl Aug 20, 2024

coretl Sep 2, 2024

DominicOram commented Sep 2, 2024


		mkdir /tmp/opi

		podman run --rm -dt --net=host -v /tmp/opi/:/epics/opi ghcr.io/diamondlightsource/eiger-fastcs:0.1.0beta5 ioc $eiger_ioc

Fastcs eiger support #528

Fastcs eiger support #528

Conversation

DominicOram commented Aug 19, 2024 • edited Loading

To Test

Notes

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DominicOram Aug 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DominicOram commented Sep 2, 2024

DominicOram commented Aug 19, 2024 •

edited

Loading

DominicOram Aug 20, 2024 •

edited

Loading