DAQ Testing/20181101

From PREX Wiki
Jump to: navigation, search

Back to Main Page >> DAQ Documentation Portal >> DAQ Testing >> DAQ Commissioning Notes

Previous Day of Testing << >> Next Day of Testing

November 1st, 2018 Testers: Cameron, Ye Tian, and Bob

See Today's Meeting Notes

Goals

  • Test QWeak ADCs in Counting House Parity DAQ to verify that the Control.db updates by Bob are working and PAN (~apar/bpan18/pan)

Testing channel mapping and PAN ADC arithmetic

For notes on 12 and 16 bit DAC calibration see July 28th DAQ Testing Notes.

To use the DACs:

  • Log into the Counting House ROC with telnet over acons1 console server (see Network Map)
  • Set the DAC output level with the C code command setDACHAPTB(DAC#,Level#)
  • Read the DAC output level with a voltmeter (as a check of functionality)
    • DAC# 1 = 12bit, 2 = 16 bit
    • 12 Bit DAC Level#, positive voltages for values that range within Level ⊂ [0, 2^12 - 1 = 4095] modularly
    • 16 Bit DAC Level#, negative to positive voltages for values that range within Level ⊂ [0, 2^16 - 1 = 65535] modularly
  • Test channel vqwk3_5 == bcmcav2r (Cameron suspects this QWeak ADC has substantial non-linearities)
    • CODA Run 4533
      • Events 0-700 -> DAC(2,0)
      • Events 700-2000 -> DAC(2,10000)
      • Events 2000-3500 -> DAC(2,20000)
      • Events 3500-5000 -> DAC(2,40000)
      • Events 5000-9000 -> DAC(2,60000)
    • Running bpan18 and "R->Draw("bcmcav2r:ev_num")" or "R->Draw("vqwk3_5:ev_num")" both show the same results (and appear to have a linear ADC response - ramp DAC function should be used)
    • Coda run 4534
      • Events 0-1000 -> Whatever hardware signal was plugged in
      • Events 1000-5000 -> DAC(2,ramping)
  • Test all Cavity BPM channels
    • CODA Run 4535 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, 2 cycles per channel)
      • Events 0-2000 -> Channel BPM B X -> vqwk3_0 - raw good, and bpmcav1xr - control.db error, fixed
      • Events 2000-4000 -> Channel BPM B Y -> vqwk3_1 - raw good, and bpmcav1yr - control.db error, fixed
      • Events 4000-6000 -> Channel BPM B Q -> vqwk3_2 - raw good, and bpmcav1r - control.db error, fixed
      • Events 6000-8000 -> Channel ??????? -> vqwk3_3 - raw good, and was wrongly mapped to bpmcav2xr, fixed
      • Events 8000-10000 -> Channel BPM C X -> vqwk3_4 - raw good, and bcmcav2xr - control.db error, fixed
      • Events 10000-12000 -> Channel BPM C Y -> vqwk3_5 - raw good, and bpmcav2yr - control.db error, fixed
      • Events 12000-14000 -> Channel BPM C Q -> vqwk3_6 - raw good, and bcmcav2r - control.db error, fixed
      • Events 14000-16000 -> Channel ??????? -> vqwk3_7 - raw good
    • CODA Run 4536 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, 2 cycles per channel)
      • Events 0-2000 -> Channel BPM B X -> vqwk3_0 - raw good, and bpmcav1xr -
      • Events 2000-4000 -> Channel BPM B Y -> vqwk3_1 - raw good, and bpmcav1yr - good
      • Events 4000-6000 -> Channel BPM B Q -> vqwk3_2 - raw good, and bcmcav1r - good
      • Events 6000-8000 -> Channel ??????? -> vqwk3_3 - raw good,
      • Events 8000-10000 -> Channel BPM C X -> vqwk3_4 - raw good, and bpmcav2xr - good
      • Events 10000-12000 -> Channel BPM C Y -> vqwk3_5 - raw good, and bpmcav2yr - good
      • Events 12000-14000 -> Channel BPM C Q -> vqwk3_6 - raw good, and bcmcav2r - good
      • Events 14000-16000 -> Channel ??????? -> vqwk3_7 - raw good
    • CODA Run 4537 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, 2 cycles per channel)
      • Events 0-2800 -> Channel BPM D X -> vqwk4_0 - worked, good raw and named
      • Events 2800-4500 -> Channel BPM D Y -> vqwk4_1 - worked, good raw and named
      • Events 4500-6500 -> Channel BPM D Q -> vqwk4_2 - worked, good raw and named
      • See plots of raw and named vs. event number, and correlation between the two.
    • CODA Run 4538 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, 2 cycle per channel)
    • CODA Run 4539 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, ~1 cycle per channel)
      • Events 0-2000 -> Channel -> vqwk0_0 - good
      • Events 2000-4000 -> Channel -> vqwk0_1 - good
      • Events 4000-6000 -> Channel -> vqwk0_2 - ??? retry
      • Events 6000-8000 -> Channel -> vqwk0_3 - ??? retry
      • Events 8000-11000 -> Channel -> vqwk0_4 - good
      • Events 11000-13000 -> Channel -> vqwk0_5 - good
      • Events 13000-15000 -> Channel -> vqwk0_6 - good
      • Events 15000-17000 -> Channel -> vqwk0_7 - ??? retry
    • CODA Run 4540 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, ~3 cycle per channel)
      • Events 0-5000 -> Channel -> vqwk0_2 - good
      • Events 5000-9000 -> Channel -> vqwk0_3 - good
      • Events 9000-12000 -> Channel -> vqwk0_7 - good
    • CODA Run 4541 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, ~3 cycle per channel)
      • Events 3000-6000 -> Channel -> vqwk1_0 - good - maps to bpm4bxp
      • Events 6000-9000 -> Channel -> vqwk1_1 - good - maps to bpm4bxm
      • Events 9000-12000 -> Channel -> vqwk1_2 - good - maps to bpm4byp
      • Events 12000-15000 -> Channel -> vqwk1_3 - good - maps to bpm4bym
      • Events 15000-18000 -> Channel -> vqwk1_4 - empty
      • Events 18000-21000 -> Channel -> vqwk1_5 - empty
      • Events 21000-24000 -> Channel -> vqwk1_6 - stuck at 500e6
      • Events 24000-27000 -> Channel -> vqwk1_7 - empty
    • Question - is the mapping in the control.db file correct? The wires are labelled with xm and yp flipped relative to Control.db, which corresponds to a mirroring about the xp-ym axis, which isn't the worst confusion to have.
      • Run 4540 - Control.db setting (with current cut, calculated y vs event number): test by using the math X vs Y = R->Draw("-(18.81/sqrt(2))*(((bpm4bxp-bpm4bxm)/(bpm4bxp+bpm4bxm))-((bpm4byp-bpm4bym)/(bpm4byp+bpm4bym))):-(18.81/sqrt(2))*(((bpm4bxp-bpm4bxm)/(bpm4bxp+bpm4bxm))+((bpm4byp-bpm4bym)/(bpm4byp+bpm4bym)))")
      • Run 4540 - Wire label setting (with current cut, calculated y vs event number): test by using the math X vs Y = R->Draw("-(18.81/sqrt(2))*(((bpm4bxp-bpm4byp)/(bpm4bxp+bpm4byp))-((bpm4bxm-bpm4bym)/(bpm4bxm+bpm4bym))):-(18.81/sqrt(2))*(((bpm4bxp-bpm4byp)/(bpm4bxp+bpm4byp))+((bpm4bxm-bpm4bym)/(bpm4bxm+bpm4bym)))")
      • For reference, we think that this chunk of data stored in EPICS (with known x and y -> negative x and y, hence the -'s above) corresponds to some of the data taken in run 4540
      • Conclusion - after checking on BPM A in vqwk2_[4-7] we see that in fact the positions correlated when BPM A was in control.db and wire mapping (which agreed) but when BPM B math assumed wire mapping.
      • This problem existed on Oct 24th as well (so we didn't introduce the issue today, and Ye Tian's channel map indicated this same wiring - see haplog entry around Oct 10th or so)
      • Therefore, we swapped the cables for BPM B xm with yp so that it would agree with the control.db and with BPM A
    • CODA Run 4542 - Ramp_CH configuration running 16 bit DAC ramp function (~1000 events per cycle, ~2 cycle per channel)
      • Events 0-2000 -> Channel -> vqwk2_0 - good looks like be BCM
      • Events 2000-4000 -> Channel -> vqwk2_1 - severe non-linearity
      • Events 4000-6000 -> Channel -> vqwk2_2 - severe non-linearity
      • Events 6000-8000 -> Channel -> vqwk2_3 - empty
      • Events 8000-11000 -> Channel -> vqwk2_4 - good
      • Events 11000-13000 -> Channel -> vqwk2_5 - good
      • Events 13000-15000 -> Channel -> vqwk2_6 - good
      • Events 15000-17000 -> Channel -> vqwk2_7 - good

Results

  • The Cavity BPM and BCM channels are correctly mapped in the counting house control.db and we are also able to see the same signals with perfect correlation to the raw signals when using the PAN names (after fixing one small bug).
  • The _1, _2, and _3 channels in vqwk2 and the last 4 channels in vqwk4 are messed up, and vqwk4_5 has severe non-linearity, along with vqwk2_1 and _2.
  • We made a new run configuration that lets us use the rampdac16 .crl functionality in the Counting House alone.
  • We rewired BPM B in vqwk1 so that it matched the control.db and BPM A wiring.

To Do

  • We can confidently use the Cavity BPM signals in the Parity DAQ for future tests now (we have verified ADC functionality for those channels).
  • A potentially confounding issue with SEE BPM B was resolved. There was a mirroring about the ym-xp axis that was fixed by swapping the wiring of yp and xm.