Periscope Pathing

[ZLLentz]

After talking to Teddy about this, I went through the code and thought about this issue a lot more... I think it deserves a write-up. Apologies in advance for the wall of text:

The addition of the periscope line causes us issues compared to the others because the path is no longer a nice tree structure, it becomes a more general directed graph. This is a quick brain dump about this problem and potential solutions.

Issues:

• Destination is not enough to identify a beamline when there are 2 or more equivalent paths to the end.
• In the current schema, BeamPath objects must end if they don’t have a branching device.

These two issues combined mean that we must split the XCS lines into a ‘Periscope’ line that ends before the LODCM and an ‘XCS’ line that goes all the way through, including the inside of the LODCM (e.g. make it look like a tree). This is ok for skywalker but not for a more general use case in XCS, and we may have this problem again with some of the proposed FEE branching schemes in lcls2.

So we must do the following:

• Modify the beamlines dict in LightController to allow two paths to exist with the same destination, without compromising usability.
• Create a mechanism for BeamPaths to continue at the start of other BeamPaths without a physical branching device.
• Bonus: create a mechanism for BeamPaths to continue in the middle of other BeamPaths (Not required, just makes definitions cleaner. May be useful in lcls2)

Implementation idea:

• Add two node devices to explicitly mark graph nodes when they can’t be determined implicitly. These would be stripped from BeamPath objects at the end of __init__, but would direct the way these paths are built:
  • ContinueNode: place at the end of a BeamPath that should continue onto the beginning of another BeamPath. This would simply implement the branches property and specify a list of one element: the destination line.
  • JoinNode: place at the beginning of a BeamPath that should accept inputs from multiple BeamPaths. This should implement a new property, sources, that is a dict mapping of source BeamPath name to a suffix for the combined line.

So, with current hardware, we’d have an XCS_Periscope BeamPath and an XCS_MONO BeamPath that each end in a ContinueNode, where node.branches == [‘XCS’]. The XCS line would begin with a JoinNode right before LODCM Cr2, where node.sources == dict(XCS_Periscope=’P’, XCS_MONO=’M’). The LightController sees the branch to XCS on each line, so it calls xcspath.join. It then checks for the JoinNode and renames the BeamPath accordingly, stashing it into the beamlines dict. Eventually it reaches the XCS line itself, sees the JoinNode, deletes XCS from beamlines (it's already been duplicated/split if it has a JoinNode), and goes through the branches block for the new BeamPaths, XCSP and XCSM, instead (in case there was another branch point). At the end, all ContinueNode and JoinNode objects are stripped out, and we're left with two valid BeamPaths to the XCS interaction point, XCSP and XCSM. (Example names of course)

Let me know what you think, we need to properly handle these double paths at some point. I think the concept of node objects will be useful for things like continuing the HXD line into CXI as well.

[teddyrendahl]

I like the idea of sources. The end result of having a QComboBox with Periscope / Mono underneath the regular XCS button seems very intuitive.

I'm not sure we need to create a full Node structure. In retrospect, this would have been the cleaner implementation, but it might be overkill to add it just for this. Can we just have a dictionary that keeps the beamlines that need sources and implement it that way?

[teddyrendahl]

This will be entirely solved by #47