Difference between revisions of "DAQ Testing/20181114"

Revision as of 00:03, 15 November 2018

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

Old-Example Timing Diagram, Injector, SIS3801 - intended behavior

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

November 14th, 2018 Testers: Bob, Cameron, Ye Tian

See Today's Meeting Notes

Goals

• Revive Bob's DAQ Test Stand.
• Fix the timing in the SIS3801 so that it latches LNE before the present event's helicity information are read out, instead of whatever was going on before that did not match the diagram given in Old-Timing Diagram, Injector, SIS3801.
• Replace bad vqwk ADCs (_2 and _4, the 3rd and 5th ones in the crate) in counting house and verify that the new ones work.

Reviving Bob's DAQ Test Stand

• Bob and Ye Tian visited Bob's DAQ test stand in TEDF 1546
• They successfully
  • Fired up CODA on the test crate (ROC4)
  • Got some events and looked at ADC data
  • Assessed the spares: 10 HAPPEX ADCs, 6 VQWK ADCs, and 3 HAPPEX Timing Boards
  • The ROC4 serial connected portserver is inaccessible due to a missing wire - will be replaced and verified

SIS3801 Scaler

Checking old settings, delayed Tsettle latch LNE

• Problem - when I originally checked the data I did not read the exact channel plugged into the SIS3801 input, mainly because I didn't want to unplug anything or taint the data being collected, and partly because there were available neighboring channels in the 726 NIM-TTL level converter that some of the signals were going through.
  • Therefore I checked both the same way I did before and with taking the channel itself and plugging it into the scope (in case the wire was bad or something)
  • Result: The 726 NIM-TTL level translator is broken
    • Evidence: When two terminated cables are plugged into the level translator it behaves as was documented in previous testing
    • However: When only reading one of the two NIM output signals in the level translator, instead of the same, good signal as before, now there is that signal added into the Tstable signal. As in, the intended SIS3801 LNE signal, which is supposed to be delayed Tsettle signal is instead = Tstable + delayed Tsettle, and the part that looks like delayed Tsettle is not very healthy looking and may not count as something capable of registering a NIM true signal. Also the Tsettle signal that was being sent to the SIS3801 as the veto signal also had this issue, where it was Tstable instead (due to the same level translator), and this may have been a more significant source of logical consternation
    • Outcome: I chose to bypass the level translator for these two signals (delayed Tsettle latch, and Tsettle veto) by using the branched outputs that were going into the level translator and just sending those directly to the SIS3801.
      • This is an acceptable solution because no other copies of those two signals in the NIM-TTL level translator were being used (neither the extra TTL or NIM output, nor the ECL twisted pair channel outputs), but it does now mean that there are no open available readouts for the Tsettle (there are two not-Tstables available in general, and one goes into the delayed Tsettle generator and the other goes into the SIS3801 Tsettle veto now), and the channel multiplier all of the helicity channels are going into cannot be used to multiply further because the available sub-units have significant tails on their rising sides, which could potentially distort signals again in some unforseen way.
• Verification of resolution of SIS3801 late-latching problem (it should read out the data of the previous event while the FLEXIO reads out the current event - I think?)
  • I tried to analyze the data in Caryn's copy of Pan (and it worked, no helicity errors), but I am unable to find the relevant scalers in the ROOT trees.
  • I tried to use xcefdmp to look for the scalers and compare the SIS3801 to FLEXIO helicity information, but I also don't know where to look in there and so I was unable to proceed.
  • Run 4611 was an initial run (using quartet, 30 Hz, for Hall B running) to get a baseline set of data when the system was known to be operating in a strange way
  • Run 4612 was a run where I unplugged a lot of stuff to see what was going on, still in prior set up
  • Run 4613 is when I started fixing things
  • Run 4614 is a clean run with the "corrected" settings, and should be compared against 4611 to see if the fix worked

• Notes:
  • The STR7200 scaler gets several of its inputs from the same NIM-TTL level translator that was seen to have nonsensical outputs, and so its data should not be trusted for now
  • Looking at Caryn's ~/caryn/paninj2018/pan/controldb available control.db files I see that the problem Bob found and that Ye and I further resolved on November 1st exists in Caryn's control.db files
    • The issue is that the mapping of channels corresponding to a BPM's sub-channels (xp, xm, yp, ym) are not handled correctly by the BPM-stripline class
    • As a consequence, the raw (and probably the calculated) values are not initialized or read out correctly, and all BPM data afflicted this way in the control.db is likely not usable (unless it is just the raw channel names that have the problems, I wasn't able to confirm this)
    • Certainly, for BPM 0L01 I was unable to get meaningful X or Y information out of the raw channels, which when plotted individually were static numbers

Testing Replacements for Vqwk_2 and _4 in Counting House

I replaced Vqwk_2 with a spare board (being careful to match the address) and tested the linearity response of the channels (per November 1st testing) to see if the vqwk ADC there before was at fault or if it was something else. Obviously this means the pedestals changed, and the first 4 channels of this ADC have BPM A in them, so it does matter.

• CODA run 4615 - rampdac16 ramp function in CH configuration (30 Hz from Hall B polarization)
  • Events 0-2000: vqwk_2_0 - worked
  • Events 2000-4000: vqwk_2_1 - worked
  • Events 4000-6000: vqwk_2_2 - worked
  • Events 6000-8000: vqwk_2_3 - worked
  • Events 8000-10000: vqwk_2_4 - worked
  • Events 10000-12000: vqwk_2_5 - worked
  • Events 12000-14000: vqwk_2_6 - worked - the other channels look like I may have accidentally severed the electrical connection or caused a short while this one was being read out, either that or all of those channels went completely off (from whatever beamline elements were reading into them) at the time I was checking this channel
  • Events 14000-16000: vqwk_2_7 - worked
• CODA run 4616 - just running with all of the channels plugged in so we have some plain data with the new board

Following that successful indication that the old vqwk ADC board was likely the problem, and not the VME crate or software, I also swapped out vqwk_4 (the fifth one in the crate) with a new board (being sure to match the address).

• CODA run 4617 tests to see if the new board reads out (it didn't want to go all the way into the VME crate no matter how hard I pushed), but I already know all of the channels work because this is the board (on the left in this picture, which shows the strange part held onto the side of the board with wires) that Chandan and I tested and unnecessarily pulled out on July 30th (when we called it vqwk 3 - run number 4102.
  • Someone else can test all of the channels again if they feel like it, otherwise run 4102 is enough for me.

Results

• The test stand in TEDF 1546 works and needs a little bit of care to get back to full operation - the portserver needs a new wire
• The injector helicity information going into the SIS3801 and probably into the STR7200 scalers was tainted by the bad 726 NIM-TTL level translator, which has been bypassed, possibly fixing the problem
• The two bad boards with 7 total bad channels have been replaced and now everything works just fine in the counting house, and the two boards will be given to Chris Cuevas to see if he can repair them

To Do

• Get the ROC4 TEDF 1546 test stand portserver back online
• Begin testing all spares in the test stand, develop quick CRL tests and ROOT verification macros that can be deployed easily
• Verify the helicity data in the SIS3801, STR7200, and FLEXIO scalers are now in the correct timing and sequence
• Standardize helicity checking techniques in the injector and counting house
  • if you put them into an ADC directly (with ROOT somehow)
  • in the scalers (with xcefdmp and proper documentation)
  • in a helicity reading and then calculating script simple analyzer
• Ask Chris Cuevas to repair the two bad boards