Beam Synchronous Acquisition for IOC Engineers

1. Beam Synchronous Acquisition for IOC Engineers • Definition/Requirements • Current Implementation (based on SLC BPM Acq) • Code - MikeZ, Debbie, Mods/Test - saa • Other Ways to Do BSA • EVR IOC Setup Steps to Add BSA Functionality • Matlab Interface – see Mike Zelazny

2. Definition/Requirements • Acquire all beam-dependent scalars across multiple IOCs on the same pulse over multiple pulses of a certain kind (not just x-pulses-in-a-row) up to 120Hz. • Acquire up to 2800 values per scalar in one acquisition request. • Each value of the 2800 values can be an average of up to 1000 values. • Each acquisition request can specify: • Beam code (defines project, 1 = LCLS) • Machine conditions of interest – rate, TS, permits, etc • Maximum severity which data is considered good • Provide constant 1HZ beam-synchronous data for channel archiver and displays (reduce network load without losing synchronicity).

3. Current Implementation • Three Parts to BSA: • User request for an acquisition done by CA client. • Data gathering done on the EVG and EVR IOCs • When gathering is finished, access of prepared data waiting on IOCs done by CA clients, with checks for a good acquisition. • Only the data gathering part is discussed in this talk.

4. IOC Data Gathering BPM FEE Triggers Data I O C P N E T E V G EVR I O C CA Client CA Client EDEF Setup BSA Data • Data gathering part consists of the following actions: • EDEF (acquisition definition) setup and start request done on the EVG IOC. • 360hz checking on the EVG IOC with user notification when finished. • 360hz requests (acquisition control) sent by the EVG IOC to all EVR IOCs via fast fiber optic link. • Data checking, averaging, and array update per scalar record per request on the EVR IOCs. • For 120hz acquisition, data on EVR IOC must be available within 7.3 msec after beam or it will be lost. EDEF will finish with arrays that are not complete if this time budget cannot be met. • For an acquisition at full beam rate (ie, 120hz), if data is acquired at a lower rate (ie, 10hz), the array will not be complete. Use rate-limit bits as-needed when setting up the EDEF. • Implementation uses EPICS record processing. EDEF Flags, Pattern, etc Timing Crate BPM Crate

5. Data Acquisition Across IOCs EVG IOC EVR IOC1 EVR IOC2 Acq #1 Acq #1 Acq #1 Acq #1 nth element of all arrays for acq #1 is on the same pulse. … … … … … … … … … … … Acq #20 Acq #20 Acq #20 Acq #20 … … … … Pattern 1 Scalar 1 Scalar n Scalar 1 Scalar data – X, Y, TMIT, Phase, Amplitude, PMT, Position, Bunch Length All arrays have 2800 values

6. BPM BSA Records Done Slower GADC BSA Done EVR Event Time Line – 4 Fiducials/120Hz Beam BPM Records Ready Slower GADCs Ready All B3 BSA MUST be finished before F0 360Hz Fiducial F0 F2 F1 F3 2.8 5.6 Time (msec) 0 9.3 8.3 1.0 Process Pn-3 pattern, advance pipeline (n-3->n-2->n-1->n), and prepare BSA based on the n records L3 L0 L3 L3 B0 120Hz BEAM B3

7. Implementation – EVG IOC 360Hz Task • The 360hz event task wakes up on interrupt from the PNET module. One of its many duties is to check for a match between the new pulse’s pattern and beam code and each active EDEFs. It keeps a count of the number of measurements and the number of values in the current average per EDEF. Masks are prepared: • Pattern match • Average done • New request (clear history) • Bad data severity • A detail - pulse information is pipelined - the new pulse is actually for 3 pulses ahead. • For the current pulse, for each EDEF that matches, if the average is done, the pattern (5 “modifier” 32bit integers) and pulse ID are stored in arrays for that EDEF that match the arrays provided by the EVR IOCs for scalar data.

8. Implementation – EVG-to-EVR 360Hz Data Transfer EDEF bit masks included in 360Hz data sent by EVG to EVR. EVR IOC caches the data on data interrupt. The EVR IOC 360Hz event task is activated on the next fiducial interrupt (event code 1) and it copies the data to the end of the pipeline and then moves up the pipeline. The data are then available to BSA record processing done later in the same pulse.

9. SCAN=IO Intr, PRIO=HIGH EVR IOC BSA Record Processing (TORO example) TORO TMIT ai Record VAL, SEVR/STAT, TIME via DOL Arrays used by BSA CA client: SCAN=IO Intr, PRIO=HIGH TMIT1 bsa Record: Provides data for compress records, resets compress records, updates diagnostics TMIT1HST compress Record FLNK FLNK VAL, TIME, RES LCLS Time Stamps TORO EFTMIT ao Record Checks timestamps, averages good values, finds RMS, counts # good values in the average, scanIoRequest FLNK EDEF Masks, Time Stamps TMITCNT1HST compress Record CNT, TIME,RES . . . 360Hz Data BSA Data FLNK RMS, TIME, RES TMITRMS1HST compress Record TMIT2 to TMITF2 20 sets of records total

10. Implementation – EVG IOC – Global Event Display

11. Put new app name in reserve record – edefReserve sequence will assign next available EDEF number Implementation – EVG IOC – All EDEF Diag Display 15 user-defined requests at one time, is this enough? Issue – apps that crash before freeing. “STEAL 1H” app is using EDEF 10 until freed by the app – “STEAL 1H” can do multiple acqs System EDEFs are reserved and setup at EVG IOC boot and never freed.

12. Implementation – EVG IOC – EDEF Diag Display Turn “ON” when ready. EVG IOC 360Hz event task will turn “OFF” when finished. Turn back “ON” to flush and restart the acq. Set machine conditions – values acquired only on pulses where ALL inclusion conditions are true AND NO exclusion condition is true Beam code describes project, 1 = LCLS (0=any beam code – good for testing) Define # in each average, # measurements, severity at or above which data is not included in average. Forever option used by system EDEFs. Push “Reset Data” to blank out all BSA data arrays. Push “Release EDEF” to free this EDEF number. Name and user will be blanked out.

13. Implementation – EVG IOC – EDEF Mask Diag Display Condition (bit) names same as the SLC Database (PNBN) and ordered alphabetically in new records by the edefMask sequence. Choose conditions that define the pulses of interest. Only pulses with these conditions will provide values to the acquisition. The edefMask sequence on the EVG IOC creates the masks used by the 360Hz event task.

14. EVR IOC BSA Record Processing – Event Device Display

15. EVR IOC BSA Record Proc – Event Device Diag Display

16. EVR IOC BSA Record Processing – BSA Diag Display Copied from EDEF diag display RMS zero when # avg is 1 Last 100 values of value

17. Other Ways to Implement BSA • Buffer and stream all data and pattern to big relational database without losses like may happen with channel access. • Clients acquire all data from all IOCs using CA with extra logic to watch for missing data when at higher rates (IOC CA server runs at low priority). • In both cases, clients do their own pattern checking, timestamp validation, averaging, RMS, etc.

18. EVR IOC Setup to Add BSA Functionality • Set up the EVR and pattern databases using steps documented in LCLS Event System: • http://www.slac.stanford.edu/grp/lcls/controls/global/subsystems/timing/lclsEventHowTo.ppt • README file from the event module. • Modify ai record providing data: • Add FLNK to BSA ao record (ie, FLNK=<device>:EFTMIT) • Set TSE to event code that triggers the acquisition. Currently not needed for 120hz records (3.14.8.2) but required for rate-limited records (and newer versions of base). • Make sure lockset containing ai record is not too big. Use dblsr tool. • If SCAN=I/O Intr or Event, set PRIO=HIGH. If SCAN=Passive, make sure any record that links to the ai record is running at high priority. • If SCAN=Event, set EVNT to event code that you want to trigger the ai record. Note that all event codes come well before beam.

19. EVR IOC Setup to add BSA • Add group of BSA Records per device: • Provide a substitutions file (i.e., IOC-IN20-BP01bsa.substitutions) with a line per device. Use one of the following databases from the event module. • bsaBPMSEdef.db – BPMs • bsaTOROEdef.db – Toroids • bsaFARCEdef.db – Faraday Cups • bsaBLENEdef.db – Bunch Length Monitors • bsaPMTEdef.db – Photo-Multiplier Tubes • bsaWIREEdef.db – Wire Scan Positions • bsaAMPLEdef.db – LLRF Amplitudes • bsaPHASEdef.db – LLRF Phases • bsaATTREdef.db – Any device – this file has a lot of macros

20. BSA Diagnostics Display • Related display buttons for each EDEF are provided from the per-device event device diagnostics page. Or add these buttons to your own displays somewhere. Each button can use one of the following displays in $EDM/event: • evnt_bsa_bpm.edl – BPMs (X,Y,TMIT) • evnt_bsa_dev.edl – Toroids and other 1 scalar devices • evnt_bsa_llrf.edl – LLRF (Phase and Amplitude) • evnt_bsa_ws.edl – Wire Scanners (PMTs and position)

21. Testing BSA • Test that the ai record is properly timestamped. • camonitor <ai record> <ioc>:PATTERN.L <ioc>:PATTERN.C • Reserve an EDEF and check the .NUSE of the resultant waveforms. • In the lab where hardware and hardware triggers may not be available but there is a functioning EVG and fiber link to your EVR, test BSA with a simulated ai record by setting fields on the ai record: • SCAN=Event • EVNT=<event code of interest> • PRIO=HIGH • Remember to set the VME IRQ of the event code of interest from the EVR display.

22. Add BSA to Clients • Let High-Level-App group know when the device supports BSA. They can help you test that it’s working. • Consider adding the “1H” (1Hz system EDEF) BSA PVs to channel archiver instead of your input PVs which update at a higher rate. All “1H” PVs in the archive will then be synchronous. • Consider using the “1H” BSA PVs on higher level EDM displays remembering that these PVs freeze at the last good value when beam goes away. May want to add something to indicate beam-ness or color-code based on the severity of the higher-rate input PV.