...

• (done) Move to Rogue 6: v 1.0.0
• current configuration time is long at 34s
  • some progress on this: now 10s according to Ric (check that we're down to 2-3 seconds that rogue sees?)
• fiber-power monitoring on the detector side and kcu1500
  • not there yet on march 22, 2024
  • (done for the detector as of v1.1.5 of epix-hr-m-320k)
• (done?) have to manually lock the lanes between ASICs and managing FPGA by running 1000 events: feels awkward-ish
  • what does epixHR do?
• not all lanes in an ASIC lock (can perhaps be fixed with improved delay settings)
  • most have 3-5 lanes that don't function or are unstable (out of 24) for unit 0xbf
• data is currently scrambled (not natural order)
  • ric is descrambling ASICS in software, but would like to move to hardwarefirmware
• (done) remove epixViewer imports in _Root.py
• on May 11, 2024 lost timing link from epixM to xpm7 (had to power cycle).  Include Julian's latest link fixes in your firmware.
• need eye-scanning for all transceiver links
• add batcherEventBuilder to kcu1500
  • use Lcls2EpixHrXilinxKcu1500Pgp4_10Gbps, which contains a BEB
  • make the ePixM devGui compatible
• (done) remove 8 bytes of null padding between timing header elements
• fix set-registers-before-each-charge-injection-event issue
  • Implement FPGA registers to rearm ASICs on each event when test register is true?
• (done) Split prepareChargeInjection() into 2 functions, the first taking first and last column (as now) and the second taking a 384 element numpy array (e.g., setupChargeInjection(self, asicIndex, lane_selected, pulserValue))
• (done) Since the scan work, normal data taking runs now see dropped and short frames from ASIC 0
• DAQ has no environmental monitoring support as yet
  • needs board re-spin (boards in layout on March 22, 2024)
• will epixM automatically increase charge with each injection pulse like epixHR?  Dionisio thinks probably not (will double-check with Lorenzo).
• (done?) zmq server port gone with rogue6?  needs to be re-added?
• need to know common-mode "bank" info
  • each lane?
  • other structures for ADC?

Miscellaneous Info

Asic readout order:

• v1.1.5 of epix-hr-m-320k introduced per detector instance yaml files, which implies that if a detector is swapped out, either:
  • the configDb for the given detector alias must be reinitialized, or
  • a different detector alias and configDb instance must be set up
    • requires corresponding .cnf changes

Miscellaneous Info

Asic readout order:

The ASICs are in this format. ASIC 0 and 1 rotated 180 degree (viewed looking at the sensorThe ASICs are in this format. ASIC 0 and 1 rotated 180 degree (viewed looking at the sensor):

0 1

3 2

Currently running on drp-neh-cmp003 and using (perhaps incorrectly) tdetsim.service.

...

• will use a new detector for beam time
• *** 5kHz epixM
  • run-trigger and daq-trigger patterns:
    • 5k,5k
    • 5k,120
    • 5k,2.5k
  • matt provides "divisors-of-5k" script which should still work
• *** timing scans
  • (done?) configuration scan
    • Looks like cas/epixhr_timing_scan.py should work for the ePixM, too
• *** fibers/nodes
  • have 11 working fiber pairs and 1 broken one. epixhr uses 3 (2 data 1 timing) epixm uses 5 (4 data 1 timing 1 register)
    • • cpo submitted Jira to fix broken fiber and add fix cassettes between 208 and src
      • need to check that all 11 are working
  • Chris Ford is tasked with running timing/data fibers in 208/srcf and by default will use cmp034 for the epixM
    • • need detector group help going from mezzanine to hutch
• *** does psana handle disabled lanes correctly?  currently the disabled lanes get a fixed number put in them (lane-number).  this may work with Mikhail's.
• tstx00417 in ~tstopr/data/drp/tst/tstx00417/xtc/ runs 313 and 314 but shape may be incorrect.
  • (done) run 316 has the data organized as (4, 192, 384).  Previously, it was (1, 384, 768).
• cable to see acquisition window on the scope?
  • dawood will check
• intensity scans
  • done by changing the beam so no work required from daq group
• pedestals
  • soft-low
  • soft-hi
  • threshold in the middle SA
  • mikhail will work on "placeholder" infrastructure but there are subtleties that we won't worry about for the beam time 
• don't necessarily need calibrated data
  • Need at least rough calibration constants to let AMI work
• (lower priority) more precisely define how we handle the gain-switching, if at all?
  • soft-low (configurable threshold at one extreme)
  • soft-high (configurable threshold at the other extreme)
  • configurable threshold in the middle
  • what are the nominal gains? nominal gain ratio is 4.7
• bit 15 is gain mode, bits 0-14 are data.  data bits may be trimmed in the future (13 or 12?)(lower priority) charge-injectionmikhail/ric are putting in placeholder code, but doesn't work: waiting for ASIC/FPGA fixare data.  data bits may be trimmed in the future (13 or 12?)
• (lower priority) charge-injection
  • mikhail/ric are putting in placeholder code, but doesn't work: waiting for ASIC/FPGA fix

ConfigDb

The configDb schema for the ePixM consists of user and expert sections.  It is set up from the lcls2/psdaq/psdaq/configdb area as follows:

python epixm320_config_store.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --dir /cds/home/c/cpo/git/epix-hr-m-320k/

The expert section holds parameters that are laid out similar to the hardware writeable reigisters.  Their names are the same as those found in devGui.  These parameters contain default settings that are written to the hardware at appropriate times.  Many of them were initialized from yaml files supplied in the epix-hr-m-320k project:

python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_ASIC_u1.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_ASIC_u2.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_ASIC_u3.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_ASIC_u4.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_PacketRegisters.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_PowerSupply_Enable.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_RegisterControl.yml
python epixhr_config_from_yaml.py --prod --user tstopr --inst tst --alias BEAM --name epixm --segm 0 --id epixm320_serial1234 --yaml Root:/cds/home/c/cpo/git/epix-hr-m-320k/software/config/ePixHRM320k_75000018efb4ab01_SspMonGrp_carrier.yml

Note that the PowerSupply_Enable file has recently been trivial and causes 'Exception: modify_device: operation failed!', but this could change in the future.  The exception is harmless.  Some of these yaml files are specific to the hardware instance of the detector.  Thus, a given ePixM DB instance will likely not work well with a different detector instance.  Also note that loading the yaml files into the DB overwrites default settings that may have been previously modified using the ConfigDb editor in Control_GUI.

The user section contains several parameters that are used to determine values for parameters written to the hardware.  The resulting values override values from the expert section in some cases and are not reflected there.  In the case of user.gain_mode, for example, values for the CompTH_ePixM and Precharge_DAC_ePixM parameters are taken from the table above (in Pedestal Scans and Charge Injection) for modes 0, 1 and 2, but the values stored in the expert section are used for mode 3.

Detector Interface: DAQ-Segments With Multiple Free-Floating ASICs

...

The location where the data is recorded is governed by the .cnf file.  With epixM.cnf as originally provided, this is the Lustre filesystem at /drpneh/data.  This path is accessible only from drp-neh-cmp0XX nodes.  The full path of the data files can be found in the log files.

Details

Run the DAQ as follows:

...