Topic | Question | Answers | Contacts |
RRL GUI- user access levels |
E.g.
| This will require more followup and discussion with stakeholders regarding conops. | |
User Interface: Operations from Control room | For remote operations of RRL control system: are we allowing multiple users to control the system simultaneously? lock controls?
| At LCLS we do not enforce any resource locking (meaning ensuring only one GUI controls any given device). While there are occasional competitions for device controls, it is never at the risk of equipment safety. It is simpler to leave our control system network open to any authenticated user, and make use of a detailed caput (channel-access write), log to determine if there are concurrent conflicts and resolve them. The complexity we're trying to avoid is unintentional, obstructive lockout, and we want to preserve multi-user operation for assisted operations, etc. | |
System interface: Vacuum System | LLNL provides/controls turbopumps but request SLAC’s roughing pump for initial compressor vessel pump down. Interface to MEC-U vacuum system: request rough vacuum for compressor vessel. | Interesting. Never split a vacuum system like that before. Inter-system vacuum interface should look something like this: Treaty interface between two systems (last template on the page). ie. perhaps the llnl vacuum system can open it's own valve to a rough vacuum after sensing for itself that rough vacuum is good, and the rough vacuum system is still giving an AOK signal. | |
Architecture | Explicit discussion of what layer does LLNL controls stop if we provide an EPICS solution. | Prefer low-level LLNL controls are wrapped in an EPICS interface. Also FEPs are replaced by IOC hosts and all devices are integrated using EPICS IOC. | |
DAQ | What data and diagnostic streams will go into DAQ for long term storage? | Still need to identify the laser system diagnostics that should be included in the DAQ/ archiver | |
DAQ and Experimental Control systems interface | DAQ questions: What hardware is required to interface with DAQ? | ||
MPS | MPS interface: What signal are we receiving to indicate it is safe to send light to TCO or TCX? | We should end up with a fast 24V (3us rise/fall) signal from SLAC experiment control systems to permit beam delivery from the laser systems. We could also consider how to do this with timing, but I suspect it could be straightforward to use the LLNL logic gate components to accomplish this. | |
Personnel Safety | Define interface with Personnel Safety System: | We'll need to see what this ends up being. Should be very minimal interfacing. SLAC will provide the exclusion zone and lss controls and hardware. How exactly that will work while the lasers are being developed at the partner labs is another question. | |
Timing | Timing requirements - define use of SLAC hardware for SP- Front end | Agreed. We need to sketch up how LLNL can use the timing pattern directly. | |
Timing | Timing - what are the sources of timing jitter in SLAC? | I would guess thermal drift through all the connections of the system, and the stochastic nature of the generation of electrons, and the accelerator and its power source. | Chengcheng Xu |
Timing | Is it required to maintain the same level of timing jitter when not using LCLS timing system? | The timing systems are built such that you can switch between timing generator sources. I would suspect jitter would improve if the lasers switch over to a local generator without the long-distances involved in staying locked with the xfel. |
Overview
Content Tools