Update MX beamlines to use new device factory - part 1 #975

rtuck99 · 2025-01-07T16:12:20Z

Fixes

Update MX beamlines to use new device factory #846

for I03, other beamlines to follow in separate PR on top of this one.

Also fixes the following issues:

diamond_filter was not being instantiated because python generic device types were not recognised as valid device factories.
~~device_factory did not support usage with sync v1 ophyd devices~~ These changes now in follow on PR 846 device factory support for ophyd v1 #984

Instructions to reviewer on how to test:

Dodal connect i03, i04 should still work

Checks for reviewer

Would the PR title make sense to a scientist on a set of release notes
If a new device has been added does it follow the standards
If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

codecov · 2025-01-07T16:21:19Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.52%. Comparing base (bbd76c6) to head (e656587).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #975      +/-   ##
==========================================
+ Coverage   97.48%   97.52%   +0.04%     
==========================================
  Files         148      148              
  Lines        6238     6274      +36     
==========================================
+ Hits         6081     6119      +38     
+ Misses        157      155       -2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

olliesilvester

Looks good, but I feel like we should put the part which fixes device_factory for v1 devices into a separate PR.

Also, for this issue we might as well convert all of the devices in i04, i24 and i23 to use the new instantiation

DiamondJoseph · 2025-01-09T15:48:37Z

src/dodal/beamlines/i03.py

+@device_factory()
 @skip_device(lambda: BL == "s03")


Depending on how mx-bluesky/hyperion is handling this:

Suggested change

@device_factory()

@skip_device(lambda: BL == "s03")

@device_factory(skip = BL == "s03")

or skip = (BL == "s03") if it's any clearer what is meant

At this point, I think we are likely going to remove all this s03 stuff soon as I think we have pretty much given up on the simulator.

There is a separate issue to remove the s03 system tests and I have updated that to remove s03 completely

Remove S03 beamline and system tests which require S03 mx-bluesky#631

DiamondJoseph · 2025-01-09T15:52:44Z

src/dodal/beamlines/i03.py

+@device_factory()
 @skip_device(lambda: BL == "s03")
-def flux(wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False) -> Flux:
+def flux(mock: bool = False) -> Flux:
    """Get the i03 flux device, instantiate it if it hasn't already been.
    If this is called when already instantiated in i03, it will return the existing object.
    """
    return device_instantiation(
        Flux,
        "flux",
        "-MO-FLUX-01:",
-        wait_for_connection,
-        fake_with_ophyd_sim,
+        wait=False,
+        fake=mock,


Seems to be mixing the two device factory types?

DiamondJoseph · 2025-01-09T15:54:09Z

src/dodal/common/beamlines/beamline_utils.py

+) -> Callable[[Callable[[], T]], DeviceInitializationController[T]]:
+    def decorator(factory: Callable[[], T]) -> DeviceInitializationController[T]:


This has to be D, Ophyd-Async only device, the connection logic does not work for Ophyd devices.

I have made modifications so that the device factory will now work with ophyd v1 devices.

So you have, if you can't tell that I stopped looking when I reached this point ;)

I thought MX only had the Eiger left on ophyd v1?

Plus a few other minor devices, s4_slits, etc. There is currently a GH ticket to move those across but the Eiger is the main thing, it will probably be a little while yet before that gets moved over to ophyd_async. I thought better to make a start on this.

Once they are moved over, we will be able to get rid of a whole bunch of code including the device_instantiation stuff.

Fingers quicker than brain and eyes

…vice_factory calls

…being created in the beamline

rtuck99 · 2025-01-13T13:55:07Z

Looks good, but I feel like we should put the part which fixes device_factory for v1 devices into a separate PR.

These changes now in

846 device factory support for ophyd v1 #984

Also, for this issue we might as well convert all of the devices in i04, i24 and i23 to use the new instantiation

These changes to follow in subsequent PRs

olliesilvester

The i03 changes look good, but I think there are some lingering changes which you have also made in some other PRs, would you mind taking them out of this one so that we don't end up merging the wrong features from this PR?

olliesilvester · 2025-01-17T17:12:09Z

src/dodal/beamlines/i04.py

-    wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False
-) -> DiamondFilter[I04Filters]:
+@device_factory()
+def diamond_filter() -> DiamondFilter[I04Filters]:


Doesn't really matter, but did you mean to take out this change in favour for your i04 PR?

If these lines aren't updated, then test_device_creation fails without further modifications because device_instantiation also doesn't work with generics, so then I need to fix device_instantiation as well.

DominicOram

Thanks, just one comment

DominicOram · 2025-01-21T11:46:34Z

src/dodal/utils.py

@@ -410,7 +412,27 @@ def is_any_device_factory(func: Callable) -> TypeGuard[AnyDeviceFactory]:


 def is_v2_device_type(obj: type[Any]) -> bool:


Should: Would be nice to have a test that explicitly checks this works for generics.
Could: Also testing the edge cases of not passing a class etc.

rtuck99 requested a review from a team as a code owner January 7, 2025 16:12

rtuck99 force-pushed the 846_update_mx_beamlines_to_use_device_factory branch from 1e10ec6 to 8096af2 Compare January 7, 2025 16:29

rtuck99 mentioned this pull request Jan 7, 2025

Update MX beamlines to use new device factory - Part 1 DiamondLightSource/mx-bluesky#735

Open

olliesilvester self-assigned this Jan 8, 2025

olliesilvester requested changes Jan 8, 2025

View reviewed changes

olliesilvester changed the title ~~846 update mx beamlines to use device factory~~ Update MX beamlines to use new device factory Jan 8, 2025

DiamondJoseph reviewed Jan 9, 2025

View reviewed changes

DiamondJoseph previously requested changes Jan 9, 2025

View reviewed changes

rtuck99 changed the title ~~Update MX beamlines to use new device factory~~ Update MX beamlines to use new device factory - part 1 Jan 9, 2025

rtuck99 force-pushed the 846_update_mx_beamlines_to_use_device_factory branch from 9c828ca to 7ec1f74 Compare January 10, 2025 15:55

rtuck99 added 11 commits January 10, 2025 16:17

Convert attenuator, aperture_scattergard, dcm

55216ff

Convert more ophyd v1 devices to device_factory, support kwargs in de…

0069aaa

…vice_factory calls

Migrate i03 panda, sample_shutter to device_factory

ec614a4

Convert more i03 devices to device_factory

64f1a6f

Migrate more devices to device_factory. Fix generic device types not …

9427b68

…being created in the beamline

Migrate qbpm to device_factory. Tidyup unit tests

b7eb24e

Fix things for Python 3.10

52ffa06

Make type-checking happy

7a8a97d

Remove @skip_device decorator usage for i03

a7365a7

Fix unit tests after splitting up PR

f4e63b1

Revert @skip_device changes for eiger, flux

e656587

rtuck99 force-pushed the 846_update_mx_beamlines_to_use_device_factory branch from ac0ec40 to e656587 Compare January 13, 2025 13:37

rtuck99 mentioned this pull request Jan 13, 2025

846 device factory support for ophyd v1 #984

Open

4 tasks

rtuck99 requested a review from olliesilvester January 13, 2025 13:55

This was referenced Jan 13, 2025

846 update i04 to use device_factory #986

Open

846 convert i23 to use device factory #987

Open

rtuck99 mentioned this pull request Jan 15, 2025

846 convert i24 to use device factory #990

Open

4 tasks

olliesilvester requested changes Jan 17, 2025

View reviewed changes

DominicOram requested changes Jan 21, 2025

View reviewed changes

Additional tests for generics and is_v2_device_factory

5d9b76e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update MX beamlines to use new device factory - part 1 #975

Update MX beamlines to use new device factory - part 1 #975

rtuck99 commented Jan 7, 2025 •

edited

Loading

codecov bot commented Jan 7, 2025 •

edited

Loading

olliesilvester left a comment

DiamondJoseph Jan 9, 2025

DiamondJoseph Jan 9, 2025

rtuck99 Jan 9, 2025

rtuck99 Jan 10, 2025

DiamondJoseph Jan 9, 2025

DiamondJoseph Jan 9, 2025

rtuck99 Jan 9, 2025

DiamondJoseph Jan 9, 2025

rtuck99 Jan 9, 2025

rtuck99 commented Jan 13, 2025

olliesilvester left a comment

olliesilvester Jan 17, 2025

rtuck99 Jan 21, 2025

DominicOram left a comment

DominicOram Jan 21, 2025

	@device_factory()
	@skip_device(lambda: BL == "s03")
	@device_factory(skip = BL == "s03")

		) -> Callable[[Callable[[], T]], DeviceInitializationController[T]]:
		def decorator(factory: Callable[[], T]) -> DeviceInitializationController[T]:

		@@ -410,7 +412,27 @@ def is_any_device_factory(func: Callable) -> TypeGuard[AnyDeviceFactory]:


		def is_v2_device_type(obj: type[Any]) -> bool:

Update MX beamlines to use new device factory - part 1 #975

Are you sure you want to change the base?

Update MX beamlines to use new device factory - part 1 #975

Conversation

rtuck99 commented Jan 7, 2025 • edited Loading

Instructions to reviewer on how to test:

Checks for reviewer

codecov bot commented Jan 7, 2025 • edited Loading

Codecov Report

olliesilvester left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rtuck99 commented Jan 13, 2025

olliesilvester left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DominicOram left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rtuck99 commented Jan 7, 2025 •

edited

Loading

codecov bot commented Jan 7, 2025 •

edited

Loading