You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Work In Progress

Will review/revise and send email once ready.

Attendees: Alex Wallace Ken Lauer Vinod Gopalan Mitchell Cabral 

Not Attended: Barry Fishler 

Topics:

From 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
  • 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
  • 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.
  • 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:

  • 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 a desire to evaluate and move towards it. At this moment, SLAC does not plan to commit to it. 
      • SLAC looking into if they have sufficient IT support.
      • Test application has taken 4 months for a single cluster, so doing this for all IOCs does not seem viable in the near term. 
    • Containerization
      • Deployment will continue to follow the same standards for EPICS right now. 
      • Is SLAC still planning to use containerization for IOCs?
  • 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 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. 
  • Test environments: Will you have a staging environment at SLAC that we can release/deploy to during a continuous development/integration phase?
    • Building a test-bed is a priority for SLAC, however, may not be in the timeframe that is useful for the project.
      • If there is a significant need for this, then we can push this forward. 
    • Not a show-stopper to not have this, but will provide an advantage for software engineers to find bugs earlier. 
    • 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.
  • 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 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. It is up to us how to structure it. It can talk to multiple PVs or none. 
  • 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 also be an abstraction above, does not exist at the EPICS layer.
    • Not specified to use PV access interfaces for MEC-U. PV access is not supported at all python layers currently at SLAC. 
    • Assume channel access moving forward. 
  • 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 that have mentioned these. 
  • 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?

Action Items:







  • No labels