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.

  • No labels