DAQ Meeting/20180531

From PREX Wiki
Jump to: navigation, search

Back to Main Page >> DAQ Documentation Portal >> DAQ Meetings

previous meeting << >> following meeting

Logistic information

BlueJeans calling instructions:
Toll-Free Number (U.S.& Canada): 888-240-2560
International toll number:     408-740-7256
Bluejeans CODE:         475 839 391
Bluejeans link: https://bluejeans.com/475839391


  • Bob : Get full Prex_ts.crl configuration running - cross all hurdles to full Prex experiment running
    • Fix the RHRS connection
    • Run with all components under TS control
  • Bob : Add a QWeak ADC to the LHRS
  • Long-range plan :
    • PAN, post-PAN and PAN-guin (Parity Analyze software) should all be rewritten, primarily to bring its functionality into the current group's control as JAPAN (Just Another Parity ANalyzer).


  • Morning - 9AM - Bob, Tyler, Chandan, Cameron : Connecting the RHRS again
    • The problem was that someone had unplugged our ethernet connection to the RHRS ROC 26 - reconnecting fixed this
    • The slow Event Builder problem showed up again, and so we stripped out the scripts again, and this worked
  • Success - the all-together Prex_ts.crl configuration works just fine, the data flows, and xcefdump shows the data fluctuating as expected
  • Morning - 11AM - Bob, Tyler, Chandan, Cameron : Adding a QWeak ADC to the LHRS
    • Bob has a test stand in for ADCs in the TEDf building's northwest corner
      • Has a 'tedf3' computer station, 3 (now 2) QWeak ADCs and a dozen or so Happex ADCs, and a mostly empty neighboring workspace that we should claim for further Prex work
    • We took QWeak ADC '#25' from Bob's test stand and plugged it into the LHRS ROC25 crate
      • This requires editing the .crl and cedit configurations, adding the quantity of ADCs used to them, and making sure that the hex id string (8400 for 'first QWeak ADC in a ROC', reading left to right) for the ADC is correctly set with the rotating pins
      • Plugged it into the crate and connected a NIM MPS signal from a spare translator we had found in the counting house into the ext gate in-port
      • Made sure ~/vxworks/hallavme14.boot script includes the QWeak ADC and the correct quantity of ADCs plugged in
      • Made sure tsP=0 is set in the boot script as well (or we should just download tslib.so so this stops being a problem)
      • (The RHRS got unplugged again, so we had to ignore the full Prex_ts.crl setup to test the new ADC's functionality)
  • Success - we got the QWeak ADC to work perfectly
  • To Do
    • All channels everywhere need to be checked, and Happex ADCs need to have their dynamic range and resistor settings checked as well
    • All QWeak ADCs need to have a corresponding backup Happex ADC that is already plugged in and ready to go with the exact dynamic range for signals needing to be replaced (using the new Parity analysis framework in development)
    • All of the signals and crates and networking connections should be diagrammed (as well as verified regularly) - as per Bob's presentation in apar@adaq3:~/parity/PREX_DAQ_Oct17.pdf
    • Per window electronic noise must be negligible in quadrature w.r.t. 171 ppm (counting statistics asymmetry width relevant for physics result) - basically we want our electronics to be so much better than out other limitations that we don't have to explain their problems or limitations in any papers or presentations - see David Armstrong and Bob McKeown arXiv:1207.5238 and Paul Souder and Kent Pashcke (open source) for far more technical details and explanations
    • DAQ software needs to be revived and rewritten

Bob's Formal TODO List

  • During the 2-week visit we managed to do items 1, 4, 5, 6, and the "deploy" part of 2 but not the "testing" part.
  • It was a productive visit. We have a fully working DAQ with enough Qweak ADC channels to run; but also HAPPEX ADCs in the HRS and counting room.
  • If another visit happens this summer, we'd do the "testing" part of item 2 and also 7, 8, 9. Testing the rate limit will involve learning how to configure and check the timing.
  • Item 3 (testing spares) can be done in our test stand; it doesn't need access to the hall, so we can postpone it to the Fall.
  • For the software (item 10) I'll try to have a version of "pan" ready to at least look at raw signals. But I am worried about item 10 being ready for the experiment.
  • With a fully working DAQ we could do parasitic tests this Fall, if desired.
1. Revive spectrometer crates.
2. Deploy all ADCs and test them.
3. Obtain and test the spares.
4. Build various DAQ configs with subsets of the DAQ crates.
5. Find / remake the RS485 cable between HRS to build full system.
6. Move our DAQ to new computer. 
7. Test rate limit, ensure deadtime zero.
8. Ensure that ET system fast enough for feedback.
9. Revive the synchronization-check system.
10. Online software, a bit undefined since software is changing.
   Some ideas here:
  (a) automatic production of run-dependent database
  (b) feedback
  (c) coil-pulsing
  (d) panguin (GUI showing real-time plots)
  (e) prompt analysis
  (f) e-logbook entries 
  (g) archiving EPICs data