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:
bal/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 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
E V R I O C
CA Client
CA Client
EDEF Setup
BSA Data
EDEF Flags, Pattern, etc
Timing Crate
BPM
Crate
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.

5. Data Acquisition Across IOCs
EVR IOC1
EVR IOC2
EVG IOC
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 … … … …
Scalar 1
Scalar n
Scalar 1
Pattern 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 values, # values used depends on user request

6. Slide from Patrick Krejcik, modified by saa
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. EVR Event Time Line – 4 Fiducials/120Hz Beam
BPM BSA Records Done
Slower GADC BSA Done
BPM Records Ready
Slower GADCs Ready
All B3 BSA MUST be finished before F0
360Hz Fiducial F3 F2 F1 F0
Time (msec)
1.0
2.8
5.6
8.3
9.3
120Hz BEAM B3 B0

8. Implementation – EVG IOC – Global Event Display

9. Implementation – EVG IOC – All EDEF Diag Display
Put new app name in reserve record – edefReserve sequence will assign next available EDEF number
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. EVR IOC BSA Record Processing (TORO example)
SCAN=IO Intr
<ioc>:EDEFAVGDONE.A, <ioc>:EDEFMEASSEVR.A
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
FLNK
TMIT1HST
compress Record
<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