Page History

...

These scans use the same "step" idea described above for EPICS PV step-scans, but instead alter a detector configuration object on each step.  Currently this has been done for the EPIX area detector to take data in the various gain ranges. Python code for this can be found here: https://github.com/slac-lcls/lcls2/blob/master/psdaq/psdaq/app/epixhr_pedestal_scan.py

BebDetector Timing Scan

• works with any BebDetector
• there is a control script "generic_timing_scan" in the daq environment in psdaq/psdaq/cas/generic_timing_scan.py.  assumes name "start_ns".  does not use bluesky.  could be changed to any valid config variable in a BebDetector's configuration object, but the "dictionary" variable name must be written correctly in generic_timing_scan.py (e.g. for start_ns it is [f'{args.detname}:user.start_ns']).
• each step completes when this xpm variable DAQ:NEH:XPM:2:PART:0:StepDone goes to one.  This variable DAQ:NEH:XPM:2:PART:0:StepGroups says which readout groups to enable/disable.
• start_ns has a minimum value determined by the L0Delay setting for the readout group.
  • L0Delay is in units of 14/13us has a range of 0-100 (there's an off-by-one somewhere).  We get notification of beam ~95us early (ideally 100us, but the beam is faster than the timing packet) so for fast detectors we want to set L0Delay to about 95:  having a larger number reduces the need for DAQ buffering (front end, kcu card, but NOT cpu buffering since we can't guarantee that DMA happens promptly)
• generic_timing_scan -p 0 -C drp-srcf-mon001 --detname tmo_fzppiranha_0 --events 71000 --linear 108000 112000 1000 --record 0 -v
  • note that the start of the timing scan must respect the L0Delay setting for the readout group
• We analyzed in ami with a graph like this.  If steps were too short and the detector rates too high it was possible for ami to miss all the data for a step:

Image Added

Script Control of Run Stop/Start

...