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
- 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
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
- alternatively, configurations will be lockable during a DAQ run
- 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
Overview
Content Tools