Overview:
- required functions:
- persist data in DAQ data stream
- user accesses data in their own way (e.g. PV or however else they want)
- participate in DAQ (including trigger decision and AMI)
- want: an IOC recorder is either LCLS1 style ("old-style") or LCLS2 style ("new-style") and doesn't "switch" between the two modes
- called "new-style" because can be used with both LCLS1/LCLS2 timing
- possible counter-example: TXI (LCLS2 DAQ) getting hard-xray line which has old-style xtcav
- old-style recorders remain unchanged (the points discussed only refer to new-style recorders)
- new-style corresponds to LCLS2 DAQ (either with LCLS1 or LCLS2 timing) while old-style corresponds to LCLS1 DAQ
New-Style Implementation:
- event-timestamps must originate from the LCLS2 timing system (which can be either LCLS2 or LCLS1(backwardly-compatible) values)
- IOC recorder data can be received by DRP either via PGP or ethernet (decided on case-by-case basis)
- if data received via pvAccess, configuration changes must be reported synchronously with the data
- alternatively, configurations will be lockable during a DAQ run so they don't change
- trigger configuration interface via pvAccess should be standardized across devices
- some fraction of the detector configuration will be made writeable by the DAQ via pvAccess
- the IOC trigger configuration must be writeable, and the DAQ will ensure the device trigger configuration mirrors the DAQ trigger configuration so timestamps can be matched
- if multiple hutches want to use the IOC recorder simultaneously, they must agree on the trigger configuration
- the DAQ will save the data in xtc2 format
Possible Old-Style Changes
Could avoid local-RAID and write to FFB directly as in the picture below.
Overview
Content Tools