Handle Multiple Sources, add source devices

[ZLLentz]

Expected Behavior

With 2 accelerators, we have 2 beams and we should be able to query which beam we have in addition to how much beam we have.

Current Behavior

No such feature

Context

LCLS2!!!

[tangkong]

With #133 and subsequent contributions, Lightpath now supports multiple sources.

Unresolved is the need to determine which beam is active, as currently we assume both sources are active and delivering beam. It might be worthwhile to present both:

• where the beam would stop if it existed (what the blocking / incident devices are)
• whether beam is passing through those upstream devices to the blocking device

It might be worthwhile to take the rectangle widgets (colored blue or grey) and use them to represent presence of beam. The icon colors, being made more consistent by #150, could be relied on to show where beam would stop and which devices are in the beam.

This is all reliant on knowing where the beam is coming from. For LCLS, this could involve querying the SXR / HXR rates (EVNT:SYS0:1:NC_SOFTRATE, EVNT:SYS0:1:NC_HARDRATE) or beam intensities (EM1K0:GMD:HPS:AvgPulseIntensity, GDET:FEE1:241:ENRC) could work.

With respect to implementation, making a device with the relevant PV first device in the HXR / SXR line and a simple Lightpath interface might be sufficient. Based on the relevant PV, the device could be the one that blocks or permits beam.

[ZLLentz]

With respect to implementation, making a device with the relevant PV first device in the HXR / SXR line and a simple Lightpath interface might be sufficient. Based on the relevant PV, the device could be the one that blocks or permits beam.

I think this is a very good approach.

With a risk of overcomplicating things: I wonder if there are other "passive reading" devices that could be used to "revise" the beam state downstream... in some real sense, such a device wouldn't be "blocking" per se but would indicate the existence of some unknown issue.

But as the first device that just says "is there even a beam at all" there isn't such a complicated consideration.

[tangkong]

With a risk of overcomplicating things: I wonder if there are other "passive reading" devices that could be used to "revise" the beam state downstream...

If those devices did exist, I'd love to have them in lightpath. I'm not quite sure if there are any truly "passive" devices, in the sense that a device has to interact and possibly attenuate the beam in order to measure some aspect of it. (in a naive sense)

[ZLLentz]

I think this is the full list:

SXR:

• GMD (in beam dump) (ionize gas, measure)
• XGMD (in FEE) (ionize gas, measure)

HXR:

• GDET (in FEE) (ionize gas, measure)
• all instances/variations of IPM (various, downstream) (diodes that catch the beam's outer "glow" without disrupting the main flow)

[tangkong]

One day I'll go through all these devices and properly learn what they do.

For the most-upstream devices (GMD/GDET), I suppose this becomes a pcdsdevices / device_config (happi) task. 🤔