Page History

Attendees: Alex Wallace Ken Lauer Vinod Gopalan Mitchell Cabral 

Not AttendedAbsent: Barry Fishler 

Questions/Topics:

...

No.	Owner	Question/Topics
1	Vinod	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?
2	Vinod	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)?
3	Vinod	Test environments: Will you have a staging environment at SLAC that we can release/deploy to during a continuous development/integration phase?
4	Barry

...

	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
5	Barry	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
6	Barry	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.
7	Barry	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?

From Vinod:

• 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?

• 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)?

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

Minutes:

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:
  • This is SLAC has a desire to evaluate and move towards it. At this moment, SLAC does Kubernetes, but do not plan to commit to it anytime soon. 
    • SLAC looking into if they have Unsure if there is sufficient IT support.Test
  • One test application has taken 4 months for a single cluster, so doing . Doing this for all IOCs does not seem viable in the near term. 
• Containerization
  • Deployment will continue Planned deployment of EPICS is to follow the same standards for EPICS right nowcurrent SLAC EPICS standards. 
  • Is SLAC still planning to use containerization for IOCs?
    • Containers SLAC can commit to containers for building and testing is something that SLAC can commit to right now. 
    • SLAC has a prototyped prototype containerized IOC currently. 
      • 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, may is not be currently in the timeframe that is useful for the project.
  • If there is a significant need for this, then we can push this needed, can be pushed forward. Not
• The absence of a test-bed is not a show-stopper to not have this, but will having it would provide an advantage for software engineers to find bugs troubleshoot earlier. 
  • Mainly LLNL is mainly concerned for the interface, not necessarily the hardware. 
  • If there is no commitment for this test-bed then we should refrain from bringing this up. 
  • Test-bed is a nice-to-have.

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

• May This may also be an abstraction above , EPICS as it does not exist at the EPICS layer.
• Not specified to use 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 labs 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