Jan. 22, 2021

with Alex R., Alex W., Zach L., Jana T., Chris F., Matt W., Silke N., Chris O.

Discussion

georgi: 100eV photon scan range over 100 seconds. 1eV/s. few microeV change per shot at 1MHz. need precision 100 microev? need to take out shot intensity (normalization)

Alex R. says encoder has 100 microev resolution, scan even faster than 1eV/s required.

Corresponds to 10kHz measurements.

silke says that old lcls1 can't be reused. old usdusb one: relative encoder (quadrature pulses) new one: absolute encoder

alex says: new encoder can only read out at 10kHz, maybe 20kHz.

zach says: add a second encoder? relative quadrature encoders faster, maybe a MHz?

silke says: "usb4" relative encoder reader can go up to 5MHz, but maybe not enough space in the vacuum environment. alex found another renishaw that goes up to 15MHz.

zach asks: why not put it on the external shaft? georgi replies not straightforward to use that as the position of the grating. zach/Alex say it could be calibrated

cpo says: interpolate? georgi says the turnaround point would break interpolation. cpo says: mechanical motor turnaround time either fast or slow on timescale of 10kHz sampling should work.  in particular, turnaround time feels likely much slower than 10kHz sampling period?

alex w.: could add time-staggered 10kHz encoders to artificially increase rate

georgi says: need to understand the upper limits. interpolation may be too short-sighted. fast encoder is best.

alex wallace renishaw: https://www.renishaw.com/en/tonic-uhv-incremental-encoder-system-with-rslm20-linear-scale--11155

ankush encoder document: https://docs.google.com/document/d/1Ho1IpT4903wkUoJMV06z5hou9to5CfAgtJBDPdBl6I4/edit?ts=600b806d

      → (Silke) this lists the USB version of the encoder we originally used the PCI version for. We now have a box as Ankush laid out, except that it 'splits' the signal, so has in&out for each encoder channel. This device its listed towards the end of Supported Control & DAQ Devices

Matt says we may have an existing board that could do the readout/timestamping

Summary of Options/Information

• 10kHz with interpolation?
• multiple encoders?
  • combine absolute/relative (may be complexity issues)
  • 2 staggered slower encoders
• need fpga timestamping
• 100 microev resolution requirement

• 	Option	max rate	work to be done	drawbacks/other consideration
  A	absolute encoder used for relevant stage	10-20(?) kHz	controls: rework PLC to send data (current solution likely ~1kHz) DAQ: likely FPGA timestamping
  B	absolute encoder used for relevant stage,  interleave with second absolute encoder	20-40 kHz	as above	need to ensure both encoders read back equivalent data, intersperse jitter from both?, same latency
  C	add a relative quadrature encoder on shaft	5 or more MHz	DAQ: need board to read signal & timestamp	complicated and possible not very reproducible mapping of measured & relevant motion
  D	add a relative quadrature encoder in vacuum	5 or more MHz	DAQ: need board to read signal & timestamp engineering: figure out how to add relative encoder

To do

• fill out the table options and costs (alex and silke)
• talk to mechanical engineers (Georgi)
• meet in two weeks

Feb. 5, 2021

Alex R., Georgi D., Chris F., Jana T., Matt W., Zach L., Joe R., Chris O.

Delay-stage scan discussion:

• It was decided that for now RIX will not do on-the-fly delay stage scans, instead using standard DAQ step scans of an electronic delay (which incur some dead time when the delay is changed)
• Georgi reserves the right to revisit this decision in the future

MHz encoder discussion:

• Feels like option D (see above) is doable according to conversation between Georgi and Danny Morton
  • they meets with Axilon next week to verify (manufacturer of mono assembly))
• Use this as our current default solution, but can still change (final decision in weeks)
• Matt W. and Ryan H. think the camlink converter box could be used for readout
  • quadrature encoder "frame format" is understood and relatively simple (absolute encoders are more difficult)
  • quadrature encoder readout can be triggered
  • might need either a new camlink converter board with new connectors or some "connector transition"
• currently no use case for high rate absolute encoders

120Hz Encoder Plans

- plc is in the fee alcove and the encoder itself is in the fee

- (decision) we put a dedicated daq evr in the controls plc node or controls evr node or drp/ctl node?
- evr gets driven by xpm fiber so trigger stops on endrun
- ttl cable to plc
- both evr and plc use BNC connectors 
- drp executable joins udp packet to timestamp from kcu (reuses TDetSim firmware).  It is new UdpEncoder, which inherits from XpmDetector (Detector Class Diagram)
- (decision) question: do we have udp direct connection or go through the router?  router is easier, but could drop the first packet and be off-by-one (can’t detect off by one with dropped shots). direct? cpo feels we should avoid the router.
- “direct” may mean a switch where we control the traffic?  (ATCA (8 sfp, 8 rj45) or top-of-rack with a new vlan?) could use it for xtcav as well.
- ready "early march”
- clearreadout means:  kcu clears its fifos, drp clears out UDP packets on configure/endrun
- ric idea: IF we could send out 1 trigger on beginrun then we could use that as the starting for future frame counters to detect a missing first packet.  not clear how to send that 1 trigger.

Mail message from Alex:

SXR servers are in R06. There’s likely space in there.
https://docs.google.com/spreadsheets/d/1woH6NHS4IrOvr2zDVZD4R8x73moTXAps1PBqADUauC4/edit#gid=1690903792
 
Our, or at least my understanding was that we can use an trigger output from any nearby host with an EVR. To be specific:
-          PLC: B940-009-R07
-          EVR: B940-009-R06 (whatever host we have running the exit slit camera)
 
I assumed the point/beauty of the EVRs is to distribute these trigger sources so it doesn’t have to originate from any specific node. We were going to include a counter in the payload so we could address any off-by-one issues. I guess it’s more complicated!
 
Sorry, Chris, I didn’t realize this thread had taken up residence elsewhere otherwise I would have responded sooner. I try to keep an eye on the pcds-it list but it’s kind of a blindspot for me.
 
The question I have at this point is, where does the Ethernet/<whatever medium we end up choosing> have to go to deliver the UDP packet?

Conversation with Georgi

May 4, 2022

• whatever we have now stays
• add a second high-rate "MHz" relative date
• in november either we have to increase the current absolute encoder rate, or do the "interpolation".  start at a few kHz.
• feels like a good chance we need interpolation mode