You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 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 configuration interface via pvAccess should be standardized
  • 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
  • No labels