LCLS Control Software Meeting Minutes, August 24, 2006

^

Contents

^

Attendees:

Agenda:

1. The goal of this meeting is to determine Application Requirements of the Event System. This includes various system events such as beam arrival.

Previous Actions:

1. None from Last Meeting.

New Actions: (summary; see details below)

1. None this meeting.

Minutes:

1. Mike Zelazny started the meeting by describing bunch length measurement using a transverse RF cavity. It included the requirements to acquire pulse-by-pulse beam data, but also to control elements in a synchronous way.
   1. A question arose about acquired pulses needing to be consecutive.
   2. Patrick indicated that we do indeed need consecutive pulses for various reasons.
   3. The supported beam rates for LCLS beam must include single pulse (one shot), 1 Hz, 10Hz, 30Hz, 60 Hz and 120Hz.
   4. The question was asked if consecutive pulses are required if beam is kicked off axis? There was no answer.
2. Stephanie suggested that we should be considering generic requirements for all applications.
   1. It was suggested that synchronous data could be categorized as a single pulse, containing N pulses, or containing N consecutive pulses.
   2. Doug suggested that all synchronized beam data could be classified as arrays of associated data, containing 1 or more elements.
   3. Stephanie mentioned there is also an issue of variation. Synchronous data might only be of interest when certain conditions are met. For instance, certain applications might only be interested in data when a 1Hz indicator bit is set.
3. We tried to identify the needs of other specific applications.
   1. Patrick said that an orbit display requires synchronized pulses from BPMs.
4. It was suggested we could classify events as:
   1. Relating to a bit Pattern,
   2. Relating to a specific pulse, or
   3. Consecutive beam pulses.
5. Stephanie mentioned that one solution is to implement an intelligent data search mechanism, to look for values in a stream of data, perhaps a specific pattern, status indicators, or a beam timestamp from a BPM.
   1. It was suggested we might consider another network protocol to allow us to do this. Perhaps we could implement this with RPC.
   2. It was agreed that an RPC or other new protocol solution might not be ready for our short-term deadlines.
6. Till suggested another solution, simply sending all of the synchronized data into a central location, and have clients retrieve them from there. He suggested Oracle as a potential solution.
   1. Patrick suggested a generic solution where all beam-synchronous IOCs maintain 10-second circular buffers. There was some discussion as to how the clients would retrieve the specific time range of interest, and a central agent such as Oracle was suggested as a potential solution.
   2. Hamid suggested that all BPM data could be buffered and made available in such a way.
7. Stephanie suggested we have a 1Hz PV available to synchronize everything which is beam-synchronous.
8. Hamid suggested we meeting again on Monday to further discuss options, and allow people to consider the suggested solutions.
9. We tried to summarize the categories of beam-synchronous applications:
   1. An application doesn't run frequently, but does some kind of control; they require consecutive pulses of buffered data, such as a bunch length measurement.
   2. An application with a lower update rate than the beam. It needs data for a 1 Hz display update only, a synchronized snapshot and possible a 1Hz average.
   3. Applications needing frequent and fast feedback; synchronized consecutive data points.
   4. SLC aware based applications.