Page History

...

Another important method (used especially for low rate 1,10,100Hz triggers that are in-synch with the beam) is to use an event-code generated by ACR (see Control Sequence Bit for currently supported event codes).  cpo thinks event codes like "SC_SXR BSA" (e.g. 100Hz is eventcode 30) on that page would be commonly used by the hutches. NOTE: We have seen empirically that these event codes do not include a destination setting, so it is necessary to also select destination 4 with the "select" field set to "inclusive" with them.  Matt writes: "Event code 30 will follow the offset used by SXR, but it isn't aware of MPS mitigating the beam rate.  We use the destination 4 filter to also pickup when MPS has inhibited the beam."

Some details:

• there are 288 bits of "event codes" available
  • some have well-defined meanings, like the low-rate ones described above (in progress)
  • 16 highest bits are hutch specific for sequences (272-287)
  • DAQ readout groups are "extra bits" included at end of timing frame
• timing frames have "destinations": e.g. bykiks, and bykikh both go to "bsy" dump
• unlike LCLS1 we will not be using event-codes to understand when bykiks has fired: use destinations instead, in particular DumpBSY for "dropped" or "background" shots
• some devices reference to "sequencer engineer number" and "sequence bit number" instead of "eventcode".  The formula to convert between the two: eventcode=(sequenceEngine#<<16 | sequencerBit#).

...