Difference between revisions of "DAQ Testing/20181127"
(→Goals) |
|||
Line 33: | Line 33: | ||
* Cameron should implement this in his ~/et-12.0/src/cameron/ etclient program that tests for deadtime online | * Cameron should implement this in his ~/et-12.0/src/cameron/ etclient program that tests for deadtime online | ||
* Cameron should consider utilizing the on or offline versions of this to verify that scalers reading helicity information are reading the correct relative events ** Just eyeballing it is sufficient for our purposes, but using this and calculating the helicity sequence offset for each copy of the sequence would be valuable as well | * Cameron should consider utilizing the on or offline versions of this to verify that scalers reading helicity information are reading the correct relative events ** Just eyeballing it is sufficient for our purposes, but using this and calculating the helicity sequence offset for each copy of the sequence would be valuable as well | ||
+ | |||
+ | === NIM-TTL Level translator health check === | ||
+ | During the [[DAQ_Testing/20181114|Nov 14th]] testing Cameron noticed issues with the signals in the scope. This was likely caused by failing to 50 Ohm terminate the signals in the scope, and the modules automatically 50 Ohm terminate, so the issues seen on the scope will not afflict the signals read in the modules. | ||
+ | |||
+ | Test: | ||
+ | * If I plug Tsettle into the NIM-TTl level translator by itself, not terminated | ||
+ | ** I get garbage | ||
+ | * If I plug in 2 signals unterminated | ||
+ | ** Looks ok, but the signal is 1.5 volts and has a long and drastically curved tail | ||
+ | * If I plug in delayed Tsettle by itself un-terminated | ||
+ | ** Tthe signal picks up the Tsettle that is either in the other channel of the NIM-TTL level translator or something | ||
+ | ** Termination is necessary | ||
+ | |||
+ | Lesson learned: Always check for 50 Ohm signal termination, and also add 50 Ohm resistors to the extra ports of NIM-TTL NIM outputs that are otherwise unused to prevent shenanigans elsewhere. | ||
+ | |||
+ | Remaining Concern: If I terminate the scope but not the second NIM out in the level translator then I get a 1.5 Volt signal rather than the NIM standard 0.8 V (and it has a bad tail) - Solution: make sure the second NIM out always gets terminated somehow. | ||
+ | |||
+ | === Injector DAQ test - Adding HEL to data stream === | ||
+ | |||
+ | '''These changes are temporary and only affect the runs described in this test''' | ||
+ | |||
+ | Adding Helicity to data stream: | ||
+ | * Added HEL+ to vqwk10_5 (the only open vqwk channel, in Caryn's injector pan this apparently used to be a BCM, but it is otherwise empty now) | ||
+ | * Investigate Voltage to Frequency (V2F) converter - V2F channels are located in a mounted relay station between the main two sets of VME modules | ||
+ | ** Relay Station Inputs 1-16: Are being routed through the left-most V2F unit into the first 16 inputs of the SIS3801 Scaler | ||
+ | *** Input 1 (in the mounted relay station): A copy of the vqwk_veto Vetoed Tstable signal that is used as the EXT Vqwk gate | ||
+ | *** (For this test) Input 2: I added a NIM HEL+ copy here | ||
+ | *** Inputs 2-16: Empty | ||
+ | ** Relay Station Inputs 17-32: Also empty, but these channels are not being routed througha V2F into the SIS3801 scaler | ||
+ | * SIS3801 Scaler inputs (0-31) - I added some copies of HEL+ - 0-15 are the left-most V2F, 16-31 are the NIM-TTL Level Translator's ECL twisted pair outputs | ||
+ | ** Channel 0: V2F Input 1 = vqwk ext signal | ||
+ | ** Channel 1: V2F HEL+ copy | ||
+ | ** Channel 2-15: Empty | ||
+ | ** Channel 16-18: 4 MHz NIM outs of V2F clocks (going from left to right, 16 is the one that the scaler channels 0-15 come from) | ||
+ | ** Channel 19-30: Empty | ||
+ | ** Channel 31: NIM->ECL copy of HEL+ (for some runs, then it was taken out and the HEL+ multiplication was moved to a different channel multiplier), otherwiser Empty | ||
+ | * I also added a HEL+ copy to FLEXIO channel 15 (the last channel), and HEL+ was already in the control bits of SIS3801 and FLEXIO | ||
+ | * '''So for these tests HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM) for all runs''' | ||
+ | |||
+ | ==== Testing Injector DAQ timing with HEL+ information ==== | ||
+ | |||
+ | * Run 4662 - "Injector" config test that it works | ||
+ | * '''Run 4663''' - 9000 event test with all HEL+ signals added as described above (this should be a the golden run for how the DAQ has been set up) | ||
+ | ** HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM) | ||
+ | ** It works (at least appears to) in Pan - I can see the [[:media:HelicityTest.png|Helicity iformation in vqwk10_5]] and in tirdata variables are correlated with each other (though there appears to be a sign flip between the two) | ||
+ | *** Is "tirdata" a FLEXIO helicity signal? It is claiming to be decoded from a "tir" device in the control.db in apar@adaq3:~/caryn/paninj2018/pan/control.db* | ||
+ | ** It [[:media:Scaler0_31-helicity.png|looks like the scaler (ECL input) data is not being decoded by Pan correctly, or there is a problem with the input channels]] | ||
+ | *** The input looks like [[:media:Scaler0_31-helicity.png|this]], and it actually [[:media:Scaler-vs-vqwk-helicity-correlation.png|correlates with the HEL+ control bit plugged into the SIS3801 as well]] | ||
+ | *** Paul King says this is probably because Pan is not decoding the Header control bit words separately from the scaler words | ||
+ | *** When I unplug the HEL+ control bit, the data from the scaler channels no longer has this correlation (instead of the left side being raised, both sides of [[:media:Scaler-vs-vqwk-helicity-correlation.png|this kind of plot]] are equal level) | ||
+ | *** Nonetheless, no matter what signals I plugged into the scaler channel, the first 4 channels (0-3) read as flat lines as a function of event number, and the rest all had the same behavior, though they did appear to not all be exactly the same signal, and would change magnitude if I changed what signals were plugged in (so its probably just a decoding issue) | ||
+ | * Run 4664 - It looked like the scaler channels were all inverted in the NIM-TTL ECL flat cable output (the notch was on the wrong side), so I flipped the cable around (which will invert the input-output channel mapping and flip the polarity of the ECL signals) | ||
+ | ** The ramping direction of the scaler looks to have changed behavior, but the jumps between events are so large its hard to tell if it changed due to me flipping the cables or not | ||
+ | * Run 4665 - I un-flipped the ECL-flat cable, and now I took the HEL+ multiplying signal out of the top (scaler channel 31) NIM-TTL level translator channel and changed that multiplying to be in a separate channel multiplexer, to make sure there wasn't any crosstalk in the NIM-TTL level translator | ||
+ | ** No (noticeable) change in Pan decoded data | ||
+ | * Run 4666 - I removed the HEL+ signal from the SIS3801 scaler input to see if that changes behavior | ||
+ | ** No (noticeable) change in Pan decoded data | ||
+ | * Run 4667 - I Removed HEL+ from the control bit of SIS3801 (and put the scaler HEL+ input back in) | ||
+ | ** Bug: This removes the HEL+ correlation of the scaler readout channels, making me thing it is a Pan decoding bug that made the correlation appear in the first place and that the signal was being dominated by the control bit part of the words rather than the scaler channel readouts | ||
+ | ** Confirmed: '''The control bit into SIS3801 matches the HEL+ data that is decoded for that even coming from the Vqwk10_5 channel, and also from whatever signal has been read into the "tirdata" variable''' | ||
+ | ** Confirmed: Because the "tirdata" information continues to track nicely with the vqwk10_5 signal this means '''tirdata is not SIS3801 control bit HEL+''' | ||
+ | * Run 4668 - To make sure the issue wasn't just the V2F module in question I switched the HEL+ V2F signal to the second V2F module's input (relay channel number 20, 4th input to V2F, reads out as bit 3 in data stream) in the VME crate and also switched the twisted pair flat cable to read that V2F module's outputs | ||
+ | ** No new change from previous behavior | ||
+ | * Run 4669 - There is an EXT in channel on the V2F modules, so I plugged a Tstable signal into it (400 us after the SIS3801 LNE signal) | ||
+ | ** No new change from previous behavior other than a change of magnitude in V2F outputs | ||
+ | * After these tests I made sure the channel mapping was as in run 4665 | ||
+ | |||
+ | ==== Test the FLEXIO Marginal Timing ==== | ||
+ | After giving up on using Pan to understand the scaler data, and not being able to find the Helicity information (properly labeled at least) for the Flexio or SIS3801 Helicity inputs I moved on to testing the marginal timing of the scalers using Pan - the diagnostic is if the delayed LNE signal jumps over the point where the scaler is read out in the CRL then the sequence of helicity will be off-by-one and yield helicity sequence read errors in the Pan analysis (as was seen in | ||
+ | |||
== Results == | == Results == |
Revision as of 14:50, 28 November 2018
Back to Main Page >> DAQ Documentation Portal >> DAQ Testing >> DAQ Commissioning Notes
Previous Day of Testing << >> Next Day of Testing
November 27th, 2018 Testers: Bob, Cameron
Goals
- Verify the NIM-TTL level translator is not bad and that the real issue with DAQ_Testing/20181114 was improper signal termination in the scope
- Scan Helicity readback from scalers as a function of delay time
- Likely the readout instance is marginally close to the LNE delayed signal timing)
- It is important to verify that the FLEXIO is functioning as advertised in the FLEXIO manual
- Add Helicity information to the scalers of interest
- Find their data in the output data-stream to allow for unambiguously determining the relative timing of the scaler vs. vqwk vs. control bit readouts
- Update timing diagrams (include the 1us between start of T_settle and Helicity flipping, don't show multiple helicity flips if subsequent T_settle's aren't shown too)
- Work with Ed Jastrzembski to implement/verify the synchronization of the TS between Counting House and Injector
- Understand how to monitor data transfer in ET system using monitorGui
- Understand DAQ deadtime implications
- Figure out the parameters to be tweaked to allow data to flow unobstructed
- If this doesn't yield an obvious solution, explore a homemade data buffer solution that allows for DAQ vs. online analysis decoupling
- Incorporate Helicity sequence monitor into deadtime testing and scaler testing
Work
TS Timing
Bob emailed Ed Jastrzembski asking for his support in evaluating the TS synchronization. We will likely tour the Counting House and Injector at a time convenient for Ed soon.
Helicity Sequence Monitor
Bob siphoned off the helicity sequence predictor code from the QWeak analyzer and made a standalone code that can be used to verify that no events are skipped in the data stream (offline analysis)
Next:
- Cameron should implement this in his ~/et-12.0/src/cameron/ etclient program that tests for deadtime online
- Cameron should consider utilizing the on or offline versions of this to verify that scalers reading helicity information are reading the correct relative events ** Just eyeballing it is sufficient for our purposes, but using this and calculating the helicity sequence offset for each copy of the sequence would be valuable as well
NIM-TTL Level translator health check
During the Nov 14th testing Cameron noticed issues with the signals in the scope. This was likely caused by failing to 50 Ohm terminate the signals in the scope, and the modules automatically 50 Ohm terminate, so the issues seen on the scope will not afflict the signals read in the modules.
Test:
- If I plug Tsettle into the NIM-TTl level translator by itself, not terminated
- I get garbage
- If I plug in 2 signals unterminated
- Looks ok, but the signal is 1.5 volts and has a long and drastically curved tail
- If I plug in delayed Tsettle by itself un-terminated
- Tthe signal picks up the Tsettle that is either in the other channel of the NIM-TTL level translator or something
- Termination is necessary
Lesson learned: Always check for 50 Ohm signal termination, and also add 50 Ohm resistors to the extra ports of NIM-TTL NIM outputs that are otherwise unused to prevent shenanigans elsewhere.
Remaining Concern: If I terminate the scope but not the second NIM out in the level translator then I get a 1.5 Volt signal rather than the NIM standard 0.8 V (and it has a bad tail) - Solution: make sure the second NIM out always gets terminated somehow.
Injector DAQ test - Adding HEL to data stream
These changes are temporary and only affect the runs described in this test
Adding Helicity to data stream:
- Added HEL+ to vqwk10_5 (the only open vqwk channel, in Caryn's injector pan this apparently used to be a BCM, but it is otherwise empty now)
- Investigate Voltage to Frequency (V2F) converter - V2F channels are located in a mounted relay station between the main two sets of VME modules
- Relay Station Inputs 1-16: Are being routed through the left-most V2F unit into the first 16 inputs of the SIS3801 Scaler
- Input 1 (in the mounted relay station): A copy of the vqwk_veto Vetoed Tstable signal that is used as the EXT Vqwk gate
- (For this test) Input 2: I added a NIM HEL+ copy here
- Inputs 2-16: Empty
- Relay Station Inputs 17-32: Also empty, but these channels are not being routed througha V2F into the SIS3801 scaler
- Relay Station Inputs 1-16: Are being routed through the left-most V2F unit into the first 16 inputs of the SIS3801 Scaler
- SIS3801 Scaler inputs (0-31) - I added some copies of HEL+ - 0-15 are the left-most V2F, 16-31 are the NIM-TTL Level Translator's ECL twisted pair outputs
- Channel 0: V2F Input 1 = vqwk ext signal
- Channel 1: V2F HEL+ copy
- Channel 2-15: Empty
- Channel 16-18: 4 MHz NIM outs of V2F clocks (going from left to right, 16 is the one that the scaler channels 0-15 come from)
- Channel 19-30: Empty
- Channel 31: NIM->ECL copy of HEL+ (for some runs, then it was taken out and the HEL+ multiplication was moved to a different channel multiplier), otherwiser Empty
- I also added a HEL+ copy to FLEXIO channel 15 (the last channel), and HEL+ was already in the control bits of SIS3801 and FLEXIO
- So for these tests HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM) for all runs
Testing Injector DAQ timing with HEL+ information
- Run 4662 - "Injector" config test that it works
- Run 4663 - 9000 event test with all HEL+ signals added as described above (this should be a the golden run for how the DAQ has been set up)
- HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM)
- It works (at least appears to) in Pan - I can see the Helicity iformation in vqwk10_5 and in tirdata variables are correlated with each other (though there appears to be a sign flip between the two)
- Is "tirdata" a FLEXIO helicity signal? It is claiming to be decoded from a "tir" device in the control.db in apar@adaq3:~/caryn/paninj2018/pan/control.db*
- It looks like the scaler (ECL input) data is not being decoded by Pan correctly, or there is a problem with the input channels
- The input looks like this, and it actually correlates with the HEL+ control bit plugged into the SIS3801 as well
- Paul King says this is probably because Pan is not decoding the Header control bit words separately from the scaler words
- When I unplug the HEL+ control bit, the data from the scaler channels no longer has this correlation (instead of the left side being raised, both sides of this kind of plot are equal level)
- Nonetheless, no matter what signals I plugged into the scaler channel, the first 4 channels (0-3) read as flat lines as a function of event number, and the rest all had the same behavior, though they did appear to not all be exactly the same signal, and would change magnitude if I changed what signals were plugged in (so its probably just a decoding issue)
- Run 4664 - It looked like the scaler channels were all inverted in the NIM-TTL ECL flat cable output (the notch was on the wrong side), so I flipped the cable around (which will invert the input-output channel mapping and flip the polarity of the ECL signals)
- The ramping direction of the scaler looks to have changed behavior, but the jumps between events are so large its hard to tell if it changed due to me flipping the cables or not
- Run 4665 - I un-flipped the ECL-flat cable, and now I took the HEL+ multiplying signal out of the top (scaler channel 31) NIM-TTL level translator channel and changed that multiplying to be in a separate channel multiplexer, to make sure there wasn't any crosstalk in the NIM-TTL level translator
- No (noticeable) change in Pan decoded data
- Run 4666 - I removed the HEL+ signal from the SIS3801 scaler input to see if that changes behavior
- No (noticeable) change in Pan decoded data
- Run 4667 - I Removed HEL+ from the control bit of SIS3801 (and put the scaler HEL+ input back in)
- Bug: This removes the HEL+ correlation of the scaler readout channels, making me thing it is a Pan decoding bug that made the correlation appear in the first place and that the signal was being dominated by the control bit part of the words rather than the scaler channel readouts
- Confirmed: The control bit into SIS3801 matches the HEL+ data that is decoded for that even coming from the Vqwk10_5 channel, and also from whatever signal has been read into the "tirdata" variable
- Confirmed: Because the "tirdata" information continues to track nicely with the vqwk10_5 signal this means tirdata is not SIS3801 control bit HEL+
- Run 4668 - To make sure the issue wasn't just the V2F module in question I switched the HEL+ V2F signal to the second V2F module's input (relay channel number 20, 4th input to V2F, reads out as bit 3 in data stream) in the VME crate and also switched the twisted pair flat cable to read that V2F module's outputs
- No new change from previous behavior
- Run 4669 - There is an EXT in channel on the V2F modules, so I plugged a Tstable signal into it (400 us after the SIS3801 LNE signal)
- No new change from previous behavior other than a change of magnitude in V2F outputs
- After these tests I made sure the channel mapping was as in run 4665
Test the FLEXIO Marginal Timing
After giving up on using Pan to understand the scaler data, and not being able to find the Helicity information (properly labeled at least) for the Flexio or SIS3801 Helicity inputs I moved on to testing the marginal timing of the scalers using Pan - the diagnostic is if the delayed LNE signal jumps over the point where the scaler is read out in the CRL then the sequence of helicity will be off-by-one and yield helicity sequence read errors in the Pan analysis (as was seen in