2022-11-03 MECU LLNL/SLAC Meeting

Attendees: Alex Wallace Ken Lauer Vinod Gopalan Mitchell Cabral 

Absent: Barry Fishler 

Questions/Topics:

Minutes:

1. We talked about SLAC’s desire to move towards the container/Kubernetes based IOCs development/deployment in a prior discussion. Have you finalized on using this strategy for MEC-U?

• Kubernetes:
  • SLAC has a desire to evaluate and move towards Kubernetes, but do not plan to commit to it anytime soon. 
    • Unsure if there is sufficient IT support.
  • One test application has taken 4 months for a single cluster. Doing this for all IOCs does not seem viable in the near term. 
• Containerization
  • Planned deployment of EPICS is to follow current SLAC EPICS standards. 
  • Is SLAC still planning to use containerization for IOCs?
    • SLAC can commit to containers for building and testing.
    • SLAC has a prototype containerized IOC. 
      • Hosted currently in SLAC's github here.

2. What EPICS version do you use, and do you have changes to EPICS that have not been given back to the community? Or in other words, should we be using EPICS base/extensions from SLAC’s repository (If it exists)?

• SLAC has their own set of changes to EPICS and its modules. 
• LLNL should be using SLAC's version which is hosted on github. R7.0.3.1-2.0.1
• All modules need to be built for the same EPICS version. 
  • SLAC needs to figure out which modules LLNL should use. 

3. Test environments: Will you have a staging environment at SLAC that we can release/deploy to during a continuous development/integration phase?

• If there is no commitment for this test-bed then we should refrain from bringing this up. For now, this test-bed is just a would-be-nice.
• Building a test-bed is a priority for SLAC, however, is not currently in the timeframe that is useful for the project.
  • If needed, can be pushed forward.
• The absence of a test-bed is not a show-stopper, but having it would provide an advantage for software engineers to troubleshoot earlier. 
  • LLNL is mainly concerned for the interface, not necessarily the hardware. 

4. The NIF control system software has a common plug-in for setpoints, which is list of named configurations. I’m looking for something similar that SLAC may use here within EPICS. The setpoint API calls exist across all devices and support the following functions:

• Goto_Setpoint. Sets all configuration parameters for a device/instrument to that named configuration
• At_Setpoint. Returns a Boolean confirming whether the device/instrument is configured according to the setpoint
• We then have various calls for creating setpoints including Create_Setpoint_From_Current_Configuration, Copy_Setpoint, Delete_Setpoint, Create_Setpoint
  • Nothing currently built into EPICS. Something can be developed, but more information from LLNL is needed.
    • Where do we want to use it and how do we want to use it? 
    • If this is something that needs to give complete control to the user, it may make more sense to move up to the python level (Ophyd).
  • Ophyd is extremely flexible and provides a user friendly representation of a device and can talk to multiple PVs. It is up to the user how to structure it. 

5. The PSC frameworks has a common Get_Data call which returns all of the relevant configuration and low-speed data from a device. The data is returned in JSON format and parsed by the client. My understanding of EPICS is that each data element is returned via a PV, so having a similar call is unlikely

• This may also be an abstraction above EPICS as it does not exist at the EPICS layer.
• SLAC does not specify using PV access interfaces for MEC-U. PV access is not supported at all python layers currently at SLAC.
  • Assume channel access moving forward. 

6. I could use a refresher on how your develop control system GUIs, any applicable standards you may use including standard colors that are laser goggle compatible, and the technology behind the GUIs.

• Not aware of any SLAC GUI standards, but are currently reaching out to obtain some from fellow sources that have mentioned these. 

7. For the coding standards, do you have this documented? If Cosy Labs is writing your software, do they have guidance from SLAC on coding and other quality standards?

• SLAC has standards for python, github practices (branching), and twinCAT here, but none for EPCIS or C/C++.
  • Further standards need to be developed.
  • LLNL can share C++ standards for SLAC review. 

Action Items:

• LLNL to share C++ standards for SLAC review. Follow up. Vinod Gopalan
• LLNL to provide more information regarding an EPICS setpoint API for SLAC to develop. Vinod Gopalan Barry Fishler 
• SLAC to provide GUI standards for laser systems (standards in development.). Follow up. Mitchell Cabral