Presentation
A presentation from Matt:
Recording of Matt's presentation on the timing system.
Link to Matt's presentation.
Patterns
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.
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:
(python3_env) [weaver@lcls-dev3 lcls2-timing-patterns]$ python lcls/fixed_rate_table.py
rate, Hz | factor | factors
928571 1 1
464285 2 (2,)
232142 4 (2, 2)
185714 5 (5,)
132653 7 (7,)
116071 8 (2, 2, 2)
92857 10 (2, 5)
71428 13 (13,)
66326 14 (2, 7)
58035 16 (2, 2, 2, 2)
46428 20 (2, 2, 5)
37142 25 (5, 5)
35714 26 (2, 13)
33163 28 (2, 2, 7)
26530 35 (5, 7)
23214 40 (2, 2, 2, 5)
18571 50 (2, 5, 5)
17857 52 (2, 2, 13)
16581 56 (2, 2, 2, 7)
14285 65 (5, 13)
13265 70 (2, 5, 7)
11607 80 (2, 2, 2, 2, 5)
10204 91 (7, 13)
9285 100 (2, 2, 5, 5)
8928 104 (2, 2, 2, 13)
8290 112 (2, 2, 2, 2, 7)
7428 125 (5, 5, 5)
7142 130 (2, 5, 13)
6632 140 (2, 2, 5, 7)
5306 175 (5, 5, 7)
5102 182 (2, 7, 13)
4642 200 (2, 2, 2, 5, 5)
4464 208 (2, 2, 2, 2, 13)
3714 250 (2, 5, 5, 5)
3571 260 (2, 2, 5, 13)
3316 280 (2, 2, 2, 5, 7)
2857 325 (5, 5, 13)
2653 350 (2, 5, 5, 7)
2551 364 (2, 2, 7, 13)
2321 400 (2, 2, 2, 2, 5, 5)
2040 455 (5, 7, 13)
1857 500 (2, 2, 5, 5, 5)
1785 520 (2, 2, 2, 5, 13)
1658 560 (2, 2, 2, 2, 5, 7)
1485 625 (5, 5, 5, 5)
1428 650 (2, 5, 5, 13)
1326 700 (2, 2, 5, 5, 7)
1275 728 (2, 2, 2, 7, 13)
1061 875 (5, 5, 5, 7)
1020 910 (2, 5, 7, 13)
928 1000 (2, 2, 2, 5, 5, 5)
892 1040 (2, 2, 2, 2, 5, 13)
742 1250 (2, 5, 5, 5, 5)
714 1300 (2, 2, 5, 5, 13)
663 1400 (2, 2, 2, 5, 5, 7)
637 1456 (2, 2, 2, 2, 7, 13)
571 1625 (5, 5, 5, 13)
530 1750 (2, 5, 5, 5, 7)
510 1820 (2, 2, 5, 7, 13)
464 2000 (2, 2, 2, 2, 5, 5, 5)
408 2275 (5, 5, 7, 13)
371 2500 (2, 2, 5, 5, 5, 5)
357 2600 (2, 2, 2, 5, 5, 13)
331 2800 (2, 2, 2, 2, 5, 5, 7)
285 3250 (2, 5, 5, 5, 13)
265 3500 (2, 2, 5, 5, 5, 7)
255 3640 (2, 2, 2, 5, 7, 13)
212 4375 (5, 5, 5, 5, 7)
204 4550 (2, 5, 5, 7, 13)
185 5000 (2, 2, 2, 5, 5, 5, 5)
178 5200 (2, 2, 2, 2, 5, 5, 13)
142 6500 (2, 2, 5, 5, 5, 13)
132 7000 (2, 2, 2, 5, 5, 5, 7)
127 7280 (2, 2, 2, 2, 5, 7, 13)
114 8125 (5, 5, 5, 5, 13)
106 8750 (2, 5, 5, 5, 5, 7)
102 9100 (2, 2, 5, 5, 7, 13)
92 10000 (2, 2, 2, 2, 5, 5, 5, 5)
81 11375 (5, 5, 5, 7, 13)
71 13000 (2, 2, 2, 5, 5, 5, 13)
66 14000 (2, 2, 2, 2, 5, 5, 5, 7)
57 16250 (2, 5, 5, 5, 5, 13)
53 17500 (2, 2, 5, 5, 5, 5, 7)
51 18200 (2, 2, 2, 5, 5, 7, 13)
40 22750 (2, 5, 5, 5, 7, 13)
35 26000 (2, 2, 2, 2, 5, 5, 5, 13)
28 32500 (2, 2, 5, 5, 5, 5, 13)
26 35000 (2, 2, 2, 5, 5, 5, 5, 7)
25 36400 (2, 2, 2, 2, 5, 5, 7, 13)
20 45500 (2, 2, 5, 5, 5, 7, 13)
16 56875 (5, 5, 5, 5, 7, 13)
14 65000 (2, 2, 2, 5, 5, 5, 5, 13)
13 70000 (2, 2, 2, 2, 5, 5, 5, 5, 7)
10 91000 (2, 2, 2, 5, 5, 5, 7, 13)
8 113750 (2, 5, 5, 5, 5, 7, 13)
7 130000 (2, 2, 2, 2, 5, 5, 5, 5, 13)
5 182000 (2, 2, 2, 2, 5, 5, 5, 7, 13)
4 227500 (2, 2, 5, 5, 5, 5, 7, 13)
2 455000 (2, 2, 2, 5, 5, 5, 5, 7, 13)
1 910000 (2, 2, 2, 2, 5, 5, 5, 5, 7, 13)
Event Codes
- 288 bits of "event codes":
- some have well-defined meanings (in progress)
- 16 highest bits are hutch specific for sequences
- 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
Rates
- timing arrives 100us prior to beam
- accelerator max rate is 13/14MHz=929kHz
- The 71428Hz rate is special: common between LCLS1 and LCLS2
- 928kHz is max rate, but accelerator pattern repeats every 910k buckets
Trigger Types
- timing trigger types:
- sequences
- ac-line rate (1,5,10,30Hz...)
- fixed-rate patterns (1, 10, 100, 1000, 10000, 71kHz, 929kHz)
- need to coordinate hutch sequence-pattern scripts with accelerator sequence-pattern
Sequencing Example
See https://github.com/slac-lcls/lcls2/blob/master/psdaq/psdaq/seq/seqprogram.py and https://github.com/slac-lcls/lcls2/blob/master/psdaq/psdaq/seq/burst.py for an example of how to generate complex patterns of event codes (the latter file is an argument given to the former). See also Matt's example.
In this example the XPM is configured to insert event codes 272-287 into the timing stream. Four event codes are generated by each sequence engine within the XPM. The XPM has 4 sequence engines allowing 16 event codes total.
Engine | Event Codes |
---|---|
0 | 272-275 |
1 | 276-279 |
2 | 280-283 |
3 | 284-287 |
A current example for doing this is done by executing:
(ps-4.5.24) bash-4.2$ python psdaq/psdaq/seq/seqprogram.py -h
usage: seqprogram.py [-h] [--engine ENGINE] seq pvsequence pva programming
positional arguments:
seq sequence script
pv sequence engine pv; e.g. NEH:DAQ:XPM:0optional arguments:
-h, --help show this help message and exit
--engine ENGINE sequence engine(ps-4.5.24) bash-4.2$ python psdaq/psdaq/seq/seqprogram.py psdaq/psdaq/seq/33k_35k.py DAQ:NEH:XPM:6
The event codes generation by an XPM may be queried via a status PV.
(ps-4.5.24) bash-4.2$ pvget DAQ:NEH:XPM:6:SEQCODES
DAQ:NEH:XPM:6:SEQCODES 2023-01-19 10:35:20.971
EventCode Description Rate
272 "33kHz base" 33164
273 "35kHz base" 35715
274 0
275 0
276 0
277 0
278 0
279 0
280 0
281 0
282 0
283 0
284 0
285 0
286 0
287 0
Sequence Start/Stop
Some technical details from a discussion on March 23, 2023
(1) current seq mode (only program time-in-seconds or numL1Accepts)
have to coordinate the start of an accelerator burst with the daq sequence
- are there two sequences? one for accelerator and one for daq?
not clear how much control the accelerator will want (e.g. burst
all the time for stability, but silke says can damage samples)
- each step we start one sequence:
o may also include control of accelerator, but if not
o have to coordinate the start of the daq seq with accelerator seq
o acc seq synced to 1Hz marker (everything repeats at 1Hz on
accelerator side)
o trickier to sync to rates faster than 1Hz
(2) future-firmware seq mode
- make the daq enable/disable on a user-defined event code
o would be faster on the enable since don't have to wait for 1Hz
marker. still have to understand the periodicity of the accelerator
so the user-defined event codes get sent down at the right time
but it does mean we don't need the slow 1Hz marker. some things like
laser electronic delay scanning may be faster than 1Hz so could benefit
from not using the 1Hz marker.
caveat: currently start sequences on 1Hz boundary
andor integrates over 10 shots
6 andor images in a step
mode (1):
- program 6 andor-readout-group "L1Accepts". might be set to the parent
group now in control.py
the readout group that is counted for the sequence is currently managed
by these lines in control.py. Currently defaults to the "platform" readout
group which is the primary readout group: need to make this more flexible
so we can change it to the integrating detector readout group:
self.pv_xpm_part_base = pv_base + ':XPM:%d:PART:%d' % (xpm_master, platform)
self.pva.pv_put(self.pva.pvStepEnd, self.readoutCumulative)