LCLS Control Software Meeting Minutes, September 14, 2006

Attendees:

Agenda:

Our goal is to Define APIs for Subsystems and Devices, to support EPICS Client Applications.

Minutes:

1. Diane started by saying there is pressure from Physicists to write MATLab scripts for commissioning. Sergei has written a MATLab programmer's guide, but we're missing the API description; basically, which PVs to use, what they mean and how to use them.
2. Steve asked why it's called an API. He asked if this was separate from EPICS Channel Access. Diane pointed out that it is just a list of PVs and a description of how to use them. IT is technically an API, but at a higher level than CA.
   1. Steve pointed out there is a tradeoff between using the EPICS sequencer and using MATLab, and Diane agreed.
3. Diane then reviewed the Applications that are expected to be available. These will require to have knowledge of a subsystem's API:
   1. Image Management for OTR and YAG screens. Sergei is working on that.
   2. Bunch Length applications are being addressed by Mike Zelazny. These will interact with OTRs, YAGs, and the Transverse cavity.
   3. Emittance measurement will be developed by Sergei and Debbie and will interact with OTR, YAG, Wire scanners and Magnets.
   4. Diane is addressing fast feedback loops.
   5. MATLab scripts in general.
   6. Steve suggested that XTOD Cameras will be important in the longer term, but we also need temperatures, water flow and other measurements to be made.
   7. Stephanie pointed out that trigger PVs, delay values, and associated channels would ideally be included in each subsystem.
   8. Klystron or Modulator control will have some aspect of API published. A question was raised whether we need API details on things that are only SLC controllable. Diane said No.
   9. Sheng voiced concern about the API for the Timing subsystem.
      1. Dayle agreed and suggested there could be separate templates for timing PVs.
      2. Mike said that all delays could then be consistent across subsystems. He suggested that one could use the correlation plot software from SCP to adjust timing.
   10. It was suggested that we could use a BPM timing script that calibrates timing delays automatically or manually for commissioning.
4. Diane summarized the discussion by pointing out that we still need a list of devices and attributes as EPICS PV names, and a description of how to use them. That is the API, and she showed an example.
   1. She pointed out that written descriptions are needed to understand how to perform most functions programmatically.
   2. Stephanie noted that magnets and many other SLC-aware names could not follow the published naming convention. It should be updated, and names containing 'BL' in the Position Code should be changed. She suggested that all names be consistent.
   3. Mike wanted to know more about SLC aware restrictions on PV names. Stephanie said they exist because we're using EPICS version 3.13 clients with version 3.14.8.2 servers. The basic restrictions are that names must use no more than 28 bytes, and have 3 colons.
5. Paul said the MATLab interface seems okay and the names were understood; the procedures to use them are unclear, and seemed different from the procedures previously discussed.
   1. Diane mentioned that the procedures for operations are different from procedures for device access.
   2. Steve said it would be nice to document procedures regardless of granularity.
6. Hamid asked how this should proceed. Diane suggested that we need groups to review the lists and processes.
7. Doug suggested this could include just the provider and user of any given API
8. Sheng said he would need to better understand synchronization. Till pointed out that PVs offer the lowest granularity in the API. Sheng said that specialized code should be considered too.
9. Mike asked what were the priorities.
   1. Hamid said that generally, the API definitions were important to do as soon as possible. He also mentioned that the MATLab doc is very important too, since it is needed to make use of the APIs.