search

aps-8id-dys / bluesky

XPCS bluesky instrument configuration
Other
2 stars 0 forks source link

2 area detector devices for mirror 1&2: M5/6 #17

Closed prjemian closed 2 months ago

prjemian commented 2 months ago

This area detector is on one of the flags: mr1.flag or mr2.flag. Which one?

file "/APSshare/epics/synApps_6_3/support/areaDetector-R3-13/ADVimba//vimbaApp/op/ui/autoconvert/ADVimba.ui" will be loaded macro= "P=8idaSoft:,R=flag1:,C=AVT_Alvium_G1-510m"

prjemian commented 2 months ago

The motors are part of #15.

MDecarabas commented 2 months ago

2 separate motors each with its own area detector

MDecarabas commented 2 months ago

the area detectors should be part of each respective component. Ie: mr1: has an area detector

prjemian commented 2 months ago
prjemian commented 2 months ago

Yikes!!!

[2:57 PM] Lang, Keenan C. 8idaSoft:flag1:Acquire is the current setup, with both cameras sharing plugins. I can switch that to match your listed pv if it makes it easier [2:58 PM] Jemian, Peter R Does not match standard area detector naming? [2:59 PM] Jemian, Peter R Both share? This won't be ready to use next week then. [2:59 PM] Lang, Keenan C. There are two cameras in one IOC, the cam1 naming convention doesn't really make sense for at least a single of the cameras. [3:00 PM] Jemian, Peter R I was expecting two separate area detectors. They can be in the same IOC. But, not two camera heads and one shared plugin chain. [3:01 PM] Jemian, Peter R Missing the cam1: level creates much additional software downstream. Why should this one be unusual?

prjemian commented 2 months ago

@keenanlang Will these two area detector IOCs have these plugins:

I'm not sure if we'll need these plugins, too:

prjemian commented 2 months ago

@sureshnaps @MDecarabas - Instead of making each detector part of the HHL mirror (next to all the motors), it will be much easier to create independent detectors. This allows us to create these two detectors much more simply, using the factory, just like the other area detectors.

prjemian commented 2 months ago

Area detector objects flag1ad & flag2ad created apart from mr1 & mr2 to take advantage of the area detector factory.

keenanlang commented 2 months ago

From what I have found, the cam ophyd objects take in the instance prefix as part of their construction, and don't rely on a hard-coded value. And all the code that relies on the cam object in the 8id bluesky setup refer to the ophyd object and not any specific pvs.

Thus, the entirety of the link between bluesky and needing a specific naming convention comes down to line 298 in ad_common.py

cam = ADComponent(cam_class, "cam1:")

Is this not an option that can be included in the XpcsAD_factory? From tracing the code, this just gets passed along to CamBase and isn't used in any of our code. CamBase then uses it to connect to the right PV's, so just changing this singular line into a configurable value would be enough to properly handle any configuration of the areaDetector naming. We can even leave "cam1:" as the default.

prjemian commented 2 months ago

@keenanlang - Your suggestion about "cam1:"` will be implemented as part of https://github.com/BCDA-APS/apstools/issues/984