Closed ZLLentz closed 2 years ago
Also sounds good - though going toward named inputs/outputs as in #106 would be my preference, if possible.
I think named inputs and outputs is a clear winner here :+1:
Closed by #133 , and the eventual https://github.com/pcdshub/pcdsdevices/pull/1028
Expected Behavior
Branching should be simple and consistent to configure, determined before runtime, and be able to handle cases of multiple inputs and multiple outputs.
Current Behavior
Branching is configured differently on different devices and cannot handle multiple input paths. In general, branching information is retrieved from the device at runtime through the attributes:
.branches
for a list of possible output beamlines.destination
for the current output beamlinesPossible Solution
Another off-the-cuff API suggestion (coupled with #106):
lightpath_outputs
list ahead of time for branching devices (inhappi
) to enumerate where the beam can go.tuple
of beam parameter dicts if it has multiple outputslightpath_inputs
list ahead of time for devices with multiple inputs (inhappi
) to enumerate which sources go to which input.tuple
of beam parameter dicts if it has multiple inputsContext
LCLS2 will have two sources that can go to either line. LCLS1's XCS LODCM already has two inputs.