search

DiamondLightSource / dodal

Ophyd devices and other utils that could be used across DLS beamlines
Apache License 2.0
2 stars 8 forks source link

Automatically keep I22 and P38 in sync #502

Open callumforrester opened 4 months ago

callumforrester commented 4 months ago

As a developer I would like to keep P38, at least from an ophyd point of view, as a close representation of I22. Currently they are treated as different beamlines with some similar components.

Possible Solution

Could we somehow define different versions of particular devices?

Acceptance Criteria

from https://github.com/DiamondLightSource/dodal/issues/502#issuecomment-2232766949

DiamondJoseph commented 4 months ago

A possible solution is to use the same beamline module for both, with careful @skip_device usage and care for visit directories- p38 is only ever going to be a commissioning visit(?)

DiamondJoseph commented 4 months ago

p38 is already analogous to s04 and could be treated the same way: i22.py gets BL = get_beamline_name("p38")

callumforrester commented 4 months ago

I would suggest more than just d11 and saxs in the same beamline module. I would suggest that we say d11 is saxs, or at least a testing representation of it. So the ophyd devices of P38 are a 1:1 representation of I22, even if we have to mock some devices.

stan-dot commented 1 month ago

are the PV names the same? What is stopping us from using the file as-is?

should we have BEAMLINE_NAME derived from venv?

DiamondJoseph commented 1 month ago

BL = get_beamline_name("p38")

Checks Environment Variables to see if BEAMLINE is exported (it will be on a beamline control machine).

Comparing p38.py and i22.py:

(best guess): d11 ~ saxs: "-DI-DCAM-03:" vs. "-EA-PILAT-01:", d12 ~ waxs: "-DI-DCAM-04:" vs. "-EA-PILAT-03:", d3 ~ oav: "-DI-DCAM-01:" vs. "-DI-OAV-01:"

i0 ~ i0: "-EA-XBPM-01:" vs. "-EA-XBPM-02:" linkam ~ linkam: "-EA-LINKM-02:" vs. "-EA-TEMPC-05",

panda1/2/3: match panda4, it: no equivalent device on p38 all others: sim devices on p38

d11, d12 shouldn't be exposed as -EA-PILAT-01, as they aren't Pilatuses (? should we allow this? Hopefully all plan stubs are written for StandardDetectors?) it should be added as a sim device or else repeating the values from i0 (?)

Definitely the Linkam and TetrAMM could be exposed on the same prefix

stan-dot commented 1 month ago

then we have the manual option of just applying a ternary expression for the PVs / or an if block

or we could make some decorator or such.

we'd also need to make it crash for panda4 I guess if there is an attempt to use it in a plan???

callumforrester commented 1 month ago

The specific case of a detector being a PilatusDetector if it's i22 and an AravisDetector if it's p38 is what's interesting here...

stan-dot commented 1 month ago

ok why not just a ternary expression?

not sure how different are the params, will explore this in a branch

callumforrester commented 1 month ago

To add some concrete acceptance criteria:

stan-dot commented 1 month ago

I guessed some of those, but it's great to see this clearly. Thanks!

stan-dot commented 1 month ago

BEAMLINE=p38 dodal connect i22 will test this tomorrow, together with this https://github.com/DiamondLightSource/i22-bluesky/issues/87

@DiamondJoseph please advise