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

[prjemian]

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]

The motors are part of #15.

[MDecarabas]

2 separate motors each with its own area detector

[MDecarabas]

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

[prjemian]

• See In each case, we will add a ROI and a Stats to plot the counter as well #33, ROI & STATS

[prjemian]

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]

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

• image1:
• Codec1:
• Pva1:
• Hdf1:
• ROI1:
• Stats1:

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

• Proc1:
• Over1:
• Trans1:

[prjemian]

@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]

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

[keenanlang]

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]

@keenanlang - Your suggestion about "cam1:"` will be implemented as part of BCDA-APS/apstools#984