Beam Synchronous Acquisition on IOC

1. Beam Synchronous Acquisition on IOC • Definition/Requirements • Current Implementation (based on SLC BPM Acq) • Code - MikeZ, Debbie, Mods/Test - saa • Alternative to BSA • To add BSA to an IOC, see: • http://www.slac.stanford.edu/grp/lcls/controls/global/subsystems/timing/lclsBsa.ppt

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 (aka event definition or EDEF) 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 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. • Data on EVR IOC must be available within 7.3 msec after beam or it will be lost, even when beam is less than 120hz. EDEF will finish with arrays that are not complete if this time budget cannot be met. • For an acquisition at full beam rate (ie, 30hz), 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 is all EPICS record-based. EDEF Flags, Pattern, etc Timing Crate BPM Crate

5. Data Acquisition Across IOCs EVG IOC EVR IOC1 EVR IOC2 EDEF #1 EDEF #1 EDEF #1 EDEF #1 nth element of all arrays is on the same pulse. … … … … … … … … … … … EDEF #15 EDEF #15 EDEF #15 EDEF #15 … … … … Pattern 1 Scalar 1 Scalar n Scalar 1 EVR IOC scalar data – X, Y, TMIT, Phase, Amplitude, PMT, Position, Bunch Length EVG IOC Scalar data – 32 bit patterns (6), pulse ID, timestamp secs, timestamp nsec All arrays have 2800 values, # values used depends on user request

6. IOC BSA Storage For 20 EDEFs EVR Timing pattern from EVG 1 EDEF e.g. 10 Hz 2 … BPMS:IN20:221:XHSTTH BPMS:IN20:221:YHSTTH BPMS:IN20:221:TMITHSTTH TH BR F1 F2 BPM module From BPM Data at full rate Controls network OPI Matlab X=lcaGet(‘BPMS:IN20:221:XHSTTH’); Conceptual data flow for Beam Synchronous Acquisition – 10Hz System EDEF Slide from Patrick Krejcik, modified by saa

7. 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 B0 120Hz BEAM B3

8. Implementation – EVG IOC – Global Event Display

9. 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. “alan” app is using EDEF 12 until freed by the app – “alan” can do multiple acqs System EDEFs are reserved and setup at EVG IOC boot and never freed.

10. 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 “FREE” to free this EDEF number. Name and user will be blanked out.

11. Implementation – EVG IOC – EDEF Mask Diag Display Condition (bit) names come from 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.

12. Alternative to BSA – Client does all the work! • Clients monitor all data (data, status, pattern, etc) from all IOCs using channel access. • Timestamps are checked to determine data on the same pulse. • Extra logic and retries needed for missing data when at higher rates (IOC CA server runs at low priority and may skip some updates). Also, network glitches and high traffic an issue. • Client does same pattern checking, timestamp validation, averaging, RMS, etc, now done on IOCs.

13. Background on Implementation

14. 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.

15. 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 records at the end of the pipeline and then moves up the pipeline. Records with current conditions are then available to BSA record processing done later in the same pulse. The task also triggers sequences via event to clear history and averaging when a new measurement is started.

16. SCAN=IO Intr <ioc>:EDEFAVGDONE.A, <ioc>:EDEFMEASSEVR.A EVR IOC BSA Record Processing (TORO example) TORO TMIT ai Record VAL, SEVR, timestamp Arrays used by BSA CA client: TMIT1 sSub Record: Averages good values, finds RMS, counts # good values in the average, checks timestamps TMIT1HST compress Record FLNK <ioc>:MODIFIER5.A SDIS timestamp VAL LCLS Time Stamps TMIT1GO bo Record FLNK X (SDIS) LNK1 FLNK <ioc>:MODIFIER5.B M TMITCNT1HST compress Record FLNK SDIS TMIT2GO bo Record X (SDIS) LNK2 FLNK . . . TMITEF Fanout Records L sSub and compress records reset via TMITINIT1 sequence record on acq startup. FLNK <ioc>:MODIFIER5.T TMITRMS1HST compress Record SDIS X (SDIS) TMITF2GO bo Record “LNK20” FLNK

17. EVR IOC BSA Record Processing – Event Device Display

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

19. EVR IOC BSA Record Processing – BSA Diag Display Copied from EDEF diag display RMS zero when # avg is 1 Last averaged values Various inputs/outputs to averaging sSub record Last 100 values of value