Page History
...
- will send one number per shot
- keep it simple for now (Larry/Namit have all encoder signals hooked up for future fancy behavior)
- 32-bit or 64-bit number? (how many total ticks)
- Zach thinks less than 4 billion ticks (maybe even less than 1 million)
- Larry says that the firmware bandwidth usage doesn't change in either case
- start with 32 bits for now to save daq disk space and network space
- can start daq-integration now?
- don't need daughter code (need xilinx dev board kcu105)
- rogue code GitHub repo? https://github.com/slaclab/high-rate-encoder-dev
- timestamping: done in kcu105 using the usual weaver/ruckman module
- use pgp4 6Gbit/s for
- increased trigger jitter ok? Larry says only 20-30ps RMS, so that's fine
- handling limit/set-up/alarm signals
- data sheet: https://jira.slac.stanford.edu/secure/attachment/30151/L-9517-9426-03-D_Data_sheet_TONiC_UHV_EN.pdf
- Nick says set-up is least important (says encoder readout is aligned: says that read-head is at the right distance from the strip with the ticks). this should be a one-time setup, requires breaking vacuum to fix. we think this information comes from some of the X,E,P,Q,Z signals.
- P,Q are limit (are these the end of the readout strip? X is setup, E is alarm. Z is reference-mark (like a "home" position?)
- Georgi feels reference-mark is important (although we should probably use the companion absolute encoder for this and for limit-protection)
- Alarm feels important too (corrupts data, either because going too fast or signal level too low, so should never happen)
- don't use an IOC: the DAQ will crash if the alarm goes off and absolute encoder takes care of limits/reference-mark
- Larry will include all the bit (and a latched error bit (counter?)) in the 64-bit DAQ data word, but DAQ will nominally only use alarm bit
- Larry counts alarms and reference-mark
- Not clear if we have a reference mark or not: ideally would check. Nick will email axilon to try to find out. Could check also check empirically.
- the companion absolute encoder can be used instead of the reference-mark.
- Georgi thinks absolute encoder should protect the "limits"
- we guess that it's the same for limit and alarm
- might need to latch some of these (and make them clearable)
- when does rix need interpolating absolute encoder?
- 3 months (november?)
- when does rix need high-rate relative encoder?
- spring 2024
- metastability:
- Larry reports that the way the encoder works this should not be an issue
- maximum speed (before skip-encoder-mark errors):
- spec sheet says 0.032 m/s is the max speed, but we need to convert this from linear to angular
- 1 count per nm
- 150urad per count
- multiply/divide as needed: https://www.wolframalpha.com/input?i=0.032+m%2Fs+*+%281+%2F+1nm%29+*+%281urad%2F150%29
- = 0.213 rad/s is the max speed
- We typically run this under 20 urad/s which is orders of magnitude below the calculated limit
Encoder Simulator
Chris Ford has an encoder simulator in lab3, with documentation here: UDP Encoder Interface (rix Mono Encoder). He also has committed lab3-caf-encoder.cnf to lcls2 GitHub in psdaq/psdaq/cnf/
High Rate Mono Encoder Interpolation Options
Goal: keep the parallelization happy (both ami and mpi-psana) so that every shot has an encoder value (either real or interpolated)
Note that the encoder can be used to generate XAS spectra with APD's, which are MHz devices. That's why we need high rates.
- ~5kHz of measured data is roughly the maximum readout rate
- interpolation will make the data better (if the "noise" on the plot below is really noise, Georgi feels it is too high frequency to be real, but he's not certain)
Example motor motion:
Options:
MHz Encoder Discussion (Oct 17, 2023)
cpo and Larry
Signals:
- P,Q are limits
- E is error (encoding error, typically from going too fast, or could be misalignment?)
- A,B are for calculating position
- Z is home
some get latched, there is a latch-clear
position is a signed integer. counter range is ~100 million.
errors have signal "E", counter and latch
GitHub: slaclab/high-rate-encoder-dev (devGui is there)
should we autohome (i.e. have firmware do it when it sees Z) or have scientists home it with software e.g. when absolute encoder is in the right place? maybe doesn't matter: they might use absolute encoder?
event builder has blowoff, as usual
Encoder Simulator
Chris Ford has an encoder simulator in lab3, with documentation here: UDP Encoder Interface (rix Mono Encoder). He also has committed lab3-caf-encoder.cnf to lcls2 GitHub in psdaq/psdaq/cnf/
High Rate Mono Encoder Interpolation Options
Goal: keep the parallelization happy (both ami and mpi-psana) so that every shot has an encoder value (either real or interpolated)
Note that the encoder can be used to generate XAS spectra with APD's, which are MHz devices. That's why we need high rates.
- ~5kHz of measured data is roughly the maximum readout rate
- interpolation will make the data better (if the "noise" on the plot below is really noise, Georgi feels it is too high frequency to be real, but he's not certain)
Example motor motion:
Options:
- DAQ interpolation. Ugly DAQ C++, may want to change later. Works for AMI
- "freezes" the interpolation to what is done at DAQ time: but doesn't preclude someone going back and doing a better analysis later
- what if
- "freezes" the interpolation to what is done at DAQ time: but doesn't preclude someone going back and doing a better analysis later
- what if what we think is noise is actually real vibration of the mono grating. in that case interpolation loses important information. one would test this by doing the analysis both with the raw data and with "smoothed" data to see which yields better physics resolution
- only send events with measurements to AMI? requires a ric-style python script to select AMI events
- limits statistics in AMI. in principle could get 5kHz.
- in future could avoid limited-statistics issue by going to 1MHz relative encoder
- cpo worry: we already need such a script for RIX to send the andor events to AMI. two issues:
- that script becomes more complex trying to do two things
- cpo thinks: if the (rare) andor events don't have an encoder value it will make the analysis (or ami display) tricky. would need to have "trigger overlap"
- (doesn't work for real-time analysis like ami) psana interpolation in-memory
- on SMD0 core (would dramatically complicate our most complicated psana event-builder code)
- psana "broadcasts" all the encoder data to all the cores. quite messy and would affect performance unless SlowUpdate broadcast at 10Hz was feasible
- (doesn't work for real-time analysis like ami) psana pre-processing interpolation written to a new xtc2 file
- could also analyze the shape above and write out very little information (10 numbers?): regions 1 (flat),2(sloped),3(flat),4(sloped),5(flat).
- (doesn't work because of chaos caused by batching, deadtime, arbitrary number of cores, load-balancing) DAQ repeats without interpolation.
- Ideally xtc2 would be able to say 3 (repeats 5 times) 7 (repeats 5 times). xtc2 can't say this easily.
- (preferred) or another version would be 3(deltatime=0),3(+deltatime),3(+deltatime),3,3,7,7,7,7,7,.... each core could do it's own interpolation. provides flexibility and scalability. extra data volume isn't too bad. will make user code more complex (they will have to "buffer")
- Chris Ford's thought on this "debinning": Encoder Debinning
- (too complex) treat the encoder as an integrating detector
- won't work with ami which doesn't use Mona's batching
- creates a lot of constraints with other integrating detectors: their trigger rates have to be multiples of each other with no phase difference.
...
proposed revised algorithm:
- a udp packet comes in
- puts entry in a queue (either SPSC or pvQueue)
- check the env for low/high rate event, in L1Accept thread:
- if low-rate: wait/poll for pvQueue
o check that the frame-counter increments appropriately, maybe time it out if it's the last
in the run. set damage if time-out or frame-counter skips
- if high-rate: interpolate using timestamp (have to cache the high-rate event until we get
a "bounding" low-rate event: a memory buffer)
for comparison, pvadetector algorithm:
- process() runs in epics thread (not l1accept thread)
- gets a buffer from a free-list and fills it with PV data put on the pv-queue (already timestamped)
- require same number of free-list buffers as pebble-buffers (allows deadtime
to protect the free-list buffers: need to get this idea into encoder)
protecting buffering:
- ideally size the pvQueue so it is "bigger" than the dmaQueue. then deadtime protects
the pvQueue from overflow.
o pvQueue is a low-rate queue, while dmaQueue is high-rate
- 2044 dma buffers +10% (204) for extra firmware buffers
- then we need (2044+204)/350 pvQueue buffers
Resetting Interpolating Encoder Data
Discussion on Oct. 4, 2023 with caf/claus/weaver/cpo
currently: configure launches worker, and the worker "remembers" by default
but Ric currently resets the worker memory on enable (which is good!)
should we "forget" old data under these conditions:
- new run?
- new step?
- enable?
- integrating detector pause? (hard)
propose:
- if it's not too hard, "forget" on every enable (or disable) (fallback: beginstep/ends\
tep)
o doesn't handle the integ-det-pause cause, but that's hard and
we will make that clear to the scientists (eventual solution may be 1MHz encoder)
- turns out ric already does this
MHz Encoder Discussion
(with larry on oct 17, 23)
P,Q are limits
E error
A,B is for calculating position
Z is home
some get latched, there is a latch-clear
position is a signed integer
for errors have signal, counter and latch (only error is an error in encoding, likely because going too fast)
slaclab/high-rate-encoder-dev (devGui is there)
should we autohome (i.e. have firmware do it when it sees Z) or have scientists home it with software e.g. when absolute encoder is in the right place? maybe doesn't matter?
counter range is ~100 million.
: wait/poll for pvQueue
o check that the frame-counter increments appropriately, maybe time it out if it's the last
in the run. set damage if time-out or frame-counter skips
- if high-rate: interpolate using timestamp (have to cache the high-rate event until we get
a "bounding" low-rate event: a memory buffer)
for comparison, pvadetector algorithm:
- process() runs in epics thread (not l1accept thread)
- gets a buffer from a free-list and fills it with PV data put on the pv-queue (already timestamped)
- require same number of free-list buffers as pebble-buffers (allows deadtime
to protect the free-list buffers: need to get this idea into encoder)
protecting buffering:
- ideally size the pvQueue so it is "bigger" than the dmaQueue. then deadtime protects
the pvQueue from overflow.
o pvQueue is a low-rate queue, while dmaQueue is high-rate
- 2044 dma buffers +10% (204) for extra firmware buffers
- then we need (2044+204)/350 pvQueue buffers
Resetting Interpolating Encoder Data
Discussion on Oct. 4, 2023 with caf/claus/weaver/cpo
currently: configure launches worker, and the worker "remembers" by default
but Ric currently resets the worker memory on enable (which is good!)
should we "forget" old data under these conditions:
- new run?
- new step?
- enable?
- integrating detector pause? (hard)
propose:
- if it's not too hard, "forget" on every enable (or disable) (fallback: beginstep/ends\
tep)
o doesn't handle the integ-det-pause cause, but that's hard and
we will make that clear to the scientists (eventual solution may be 1MHz encoder)
- turns out ric already does thisevent builder has blowoff
Overview
Content Tools