Comments from the 05/27/05 and 05/31/05 LCLS SLC-Aware Requirements Review: Beam Synchronous Acquisition and Controls Presenters: Diane, Debbie Attendees: Tony, Patrick, Doug, Till, Stephanie, Mike Zelazny 5/27 only: Ron Chestnut, Kristi, Dayle, others? 5/31 only: Mario, Ron Mackenzie, others? Specification: http://www.slac.stanford.edu/grp/lcls/controls/global/sw/slc_ioc/requirements/BSACFacilityReqs.htm (1) Only IOCs in the injector and linac need be SLC-aware. The plan is to have all apps converted by the time LTU and undulator are ready for commissioning. (2) In linac, straight-ahead beam may happen (instead of bypass line) but only with restrictions - if necessary, will switch back to old electronics for non-LCLS beam in linac. (3) PMTs only need to be acquired during wire scan. Should PMTs be acquired all the time anyway or should there be an start/stop action? (4) For beam synchronous control of the wire stepper motors, does the wire-scan application have any interaction with Kristi's SLC-aware magnet-like device control which may include stepper motors? Probably not. (5) Patrick and others would like the ability to set up a BPM acquisition with specific criteria to happen all the time, independent of SCP requests. For example, every time the 1 hz bit appears in the PNET pattern, a snapshot of the BPM data is saved in separate records for EDM displays. A separate discussion is needed to specify what "canned" criterias are needed. (6) Calibration requirements needs a separate review later. Calibration doesn't affect the design of the SLC-aware IOC except that we need to know if calibration is successful or not and if calibration is in-progress. (7) Linac Energy Management (LEM) - doesn't appear to add any new requirements to beam synchronous acq and control. However, if the SCP LEM is used for LCLS, then it needs to access the new LLRF IOCs which are not SLC-aware. This needs further discussion elsewhere (all-EPICS LEM?, add CA to SCP LEM?, make LLRF IOCs SLC-aware and control/acquire through non-beam-synchronous "magnet" job?). (8) Change "Watchdog" to something like "Orbit Checker". This would be some process or sequence that monitors the BPMs at a slow rate, calculates RMS, and checks against alarm limits. (9) Compatibility with camac BPMs - Mike Z. will set up the VMS side to gracefully handle the new BPMs. Ignore some things, dummy up other things like camac BPM calibration files, etc. (10) System should allow for up to 20 users, each having its own acquisition criteria. The SCP will need to share these slots with CA clients. System must be capable of processing all 20 users at 120 hz with plenty of time to spare. (11) The setup for these 20 users should be displayable for diagnostic purposes. (12) Any ignored or not-implemented SLC function code should be error logged (and Mike may be able to find and maybe fix the offending SLC app). (13) Beam strength in the BPM acq request (prep message) will not be used. (14) MPG replies back to a YY request assuming camac BPM acq - it's possible that it replies much later than needed so SCPs will make users wait longer than necessary for relatively fast IOCs. (15) SCP is limited to 2 "meas prep's" (acq setups). One SCP cannot take all 20 slots. When a SCP goes away, it gives up its slots. (16) In data flow diagrams, need to explicitly show stepper motor control. (17) Wire package requires changes to request/reply messages for stepper motor control. For example, the user-requested step size and range need to be in microns instead of camac DAC counts. Mike Z. to provide an estimate for the amount of work needed on the SCP side. (18) A wire-scan involves getting both PMT and BPM values at various places. PMTs are kept in separate ARRY units. (19) Delay between the fiducial and beam crossing due to cable delays, laser timing, etc needs to be measured by BPM timing for LCLS and the proper delay programmed into the EVR with nsec resolution. BPM timing will NOT be an SLC app. It is expected that this delay be much less than 1 msec shown on one of the diagrams. Till mentions that the software shouldn't be waiting during this delay time (question about how/if the software is triggered by the EVR). (20) During the review, questions were asked how exactly the EVR works. This needs further discussion. It is important that the EVR receive the entire 128 bit pattern and make it available for bpm acq. (21) When setting up a bpm acq for a user, the user 4 char SCP ID must be saved as part of the criteria (perhaps in place of the active flag). For a non-SLC user, some other user ID (maybe user name?) needs to be set. The SCP ID/user name is cleared when the slot is freed. (22) It should be noted in the spec that supertype 1 data ("static" data like BPMS OFFS, ANGL, XTOL) in the SLC database will not be synched with the equivalent values in the EPICS database. There are no plans to log the differences at IOC SLC startup. Both databases will need to be updated separately. (23) The spec should note that supertype 2 data like hardware configuration (HSTA) bits (online/offline, maintenance, checkout) in the SLC database are updated from EPICS (EPICS is the master) at IOC SLC startup and then kept in synch from then on with the master being either EPICS or SLC (last to change wins). (24) The 17 bit pulse ID in the reply message can be taken from the EPICS timestamp instead of determined from the 4 bits in the PNET pattern and known rules. Dayle will need to determine the 17 bit pulse ID on the PNET/EVG IOC and put it into the timestamp that she inserts into the pattern going to the EVRs. (25) There is no requirement for the SCP user bpm acq criteria be restored across IOC reboot - this is consistent with the SLC micros. SCP users will need to restart the acq after reboot. For CA clients, this may be different? Bumpless reboot will be needed for the hardware configuration bits and calibration conversion values but probably not much else. (26) No fly type motors will be supported. (27) No requirement to update BPMP and GADC supertype 3 (readback) fields from the IOC unless it is needed for acquisition. Most of these information-only fields can be viewed on an EPICS display. (28) The spec is not clear on which HSTA bits, which secondaries, and which bits in the status passed back in the reply structure are meaningful for new-style BPM acquisition. Are ARRY NORM and POLY used? Are BPMS OFFS, ANGL, XTOL used? If yes, how are they used? This information needs to be filled in as the design/implementation progresses. There probably aren't any show stoppers. (29) Currently, both the raw data and processed data is sent back to the SCP. Till may not provide the raw data. Do any of the required SLC apps need raw data? If SLC apps assume the raw data is in camac counts, then it's not useful anyway. (30) Till was not planning to provide TMIT (bunch charge). Do any of the required SLC apps need TMIT? Can they be changed to use toroid data instead? (31) Till will probably set the value to NaN and severity to invalid on a data acq failure. The processing logic will need to check for this condition. NaN cannot be sent up to VMS.