Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • the absolute encoder will continue to be used
  • perhaps add a second high-rate (maybe even MHz?) relative encoder
  • in november either we have to increase the current absolute encoder rate, or do the "interpolation".  beam starts at a few kHz.
  • feels like a good chance we need interpolation mode since the MHz encoder does not yet exist
  • existing absolute encoder may trigger at 500Hz or 1kHz, but no more
  • existing absolute encoder has estimates for velocity, acceleration, jerk, maybe more? zach can include these in the data stream fairly easily so we can see how well it does
  • for psana we will need to have an encoder readout trigger the "start" of a batch (for parallelization) similar, but different from, integrating detectors where data triggers the "end" of a batch.
    • is there a batching conflict between integrating detectors (e.g. andor) an absolute encoder?  may need to trigger the encoder at a higher-harmonic of the andor?  but maybe still a conflict because one marks the end of the batch while the other marks the beginning?

MHz Discussion

June 10, 2022 dan morton, larry ruckman, matt weaver, nick waters, zach lentz, cpo

  • dan has been interfacing with axilon (cologne, germany)
  • stick with renishaw
  • axilon designs brackets and cable routing and provides renishaw (
  • digitized signal comes out
  • lead times long
  • encoder is in the FEE (just east of entrance on massive granite)
  • need Larry/Matt/TID to do the custom timestamping: pcie with FMC and SFP for timing system
  • what are the cable-length constraints?  maybe do a wave8-style box or a dev board (only one of these at the moment?)?  prefer dev board at the moment. comes out as PGP to KCU1500 in the DRP.
  • do we need a second controls interface to this box?
    • requires an "IOC" (more work for controls group)
    • may make it easier for the scientists to use
  • need to be able to reset the counter to zero (to get absolute-encoder style behavior)
  • dan says MHz is overkill, but psana needs MHz.
  • may need errors sent back to DAQ
  • need to decide on a table-top model for TID prototype. looking at page 14 of the manual (and page 7, which shows max speed vs. clock and resolution)
    • Interpolation factor: RIX would like 1nm (20KD).  may decrease range?
    • Alarm format and conditions: A (line driven E output; all alarms)
    • Clocked output option: 50MHz
    • Options: A (This is what axilon suggested, Larry thinks he can adapt)
  • cable going into Larry's box will be as on page 5 of the manual
  • cable lengths on page 9 look good.
  • diagram on page 9 of the manual shows the analog signal getting converted to digital by TONIC interface.  Larry needs to supply 5V.
  • schedule (need to ask Georgi). mechanical install in January 2023.
  • account numbers: ask Georgi

From axilon:

“…the encoder intended to be used is:
-             Read head: T2601-15M or T1611-15M (this depends on availability, the arc can be resolved with a linear and a rotary encoder head, it is actually more a matter of how the scale is mounted and that will be done on an arc)
-             Interface: Ti20KDA06A, that is 20,000x interpolation to get the highest resolution. Note, on the interface one has to check with controls what options they may want to see, for that see below link. What is of importance are the last for letters (i.e. currently the …A06A, this is our usual default):
o            First A: this is for alarm outputs. I have to admit, I have no real clue on that, this needs to come from controls
o            06 is the max output frequency. 6 MHz in this case, often controllers have a limit of what they can take as maximum. The 6MHz is for vibrations check more than sufficient
o            Second A: some options regarding what kind of signals are output, also here this is a controls related question.https://www.renishaw.com/media/pdf/en/257d836362cd4e8189908521185ff4bd.pdf