Page History

...

It's a common question to ask what are the rates that the accelerator can generate.  The table below lists the rates that are natural for the accelerator.  These are the periodic rates that repeat exactly at the ~0.98 second period of the timing/MPS system.  Of course, we can generate other rates as well that aren't exactly periodic by doing the sort of thing you described - dropping shots or irregular sequences.  This has been useful for the OPCPA laser development in deciding the exact frequencies they will support.

Matt provides this example of how you can determine if various trigger rates overlap: 16kHz (16581 in the table) has factors (2,2,2,7).  102Hz has factors (2,2,5,5,7,13).  It's missing one factor of 2, so it only overlaps 1/2 of the time.  51Hz has (2,2,2,5,5,7,13), so it contains all the factors from 16kHz and thus overlaps 100%.

If a base accelerator rate is chosen (e.g. 33kHz) then other rates having the same prime factors as the accelerator rate are allowed, according to this table:

...

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#).

...