Xray phrun function for module

[rslu]

We have tried to take module data with pxar / xray / phrun function and we got a broken map. It's direct beam from W tube, 35kV 0.2mA, with 10kHz trigger rate and 10 s data taking. The flux should be in the ball park of 50MHz/cm2

We wasn't sure what was the problem. This afternoon, Jan came and read the module our with his python based pyXar and obtained this map with same module. data acquisition time 10s trigger rate 31.1 kHz hit rate about 60MHz/cm2

Jan told me the core of software is the same as pxar, so it much be something in the upper level of software has trouble taking module data for xray.

Cheers, Rong-Shyang

[simonspa]

I can confirm that @jhoss uses the same core library pxarCore as you do, he basically just uses the Python interface instead of the C++ one and has developed his own tests with it.

Am 1. Oktober 2014 20:22:43 MESZ, schrieb rslu notifications@github.com:

We have tried to take module data with pxar / xray / phrun function and we got a broken map. It's direct beam from W tube, 35kV 0.2mA, with 10kHz trigger rate and 10 s data taking. The flux should be in the ball park of 50MHz/cm2

We wasn't sure what was the problem. This afternoon, Jan came and read the module our with his python based pyXar and obtained this map with same module. data acquisition time 10s trigger rate 31.1 kHz hit rate about 60MHz/cm2

Jan told me the core of software is the same as pxar, so it much be something in the upper level of software has trouble taking module data for xray.

Cheers, Rong-Shyang

---

Reply to this email directly or view it on GitHub: https://github.com/psi46/pxar/issues/230

[ursl]

Hi Rong-Shyang,

your map looks funny, indeed.

As a first remark: PHrun (and in fact all tests in PixTestXray) are not intended for direct beam, but rather for monochromatic light. For the direct beam you should be using PixTestHighRate, and for imaging the module I'd use the rundaq subtest there.

What do you actually show? hit map? PH map? Q map? You do not provide the title of what is displayed.

The pattern you see in your map seems to indicate that the relative occupancy is 'OK' (one sees components on the HDI), your problem arises from something else.

If you showed a non-hit map, i.e. PH or Q map, did you verify that your PH calibration was successful?

What did you do before running this test?

Can I see a log file (with -v DEBUG, not INFO) and the root file?

Cheers, --U.

On Wed, Oct 1, 2014 at 8:22 PM, rslu notifications@github.com wrote:

We have tried to take module data with pxar / xray / phrun function and we got a broken map. [image: module_xray_w] https://cloud.githubusercontent.com/assets/5728495/4480448/793064b2-4997-11e4-9f64-876b7603168d.png It's direct beam from W tube, 35kV 0.2mA, with 10kHz trigger rate and 10 s data taking. The flux should be in the ball park of 50MHz/cm2

We wasn't sure what was the problem. This afternoon, Jan came and read the module our with his python based pyXar and obtained this map with same module. data acquisition time 10s trigger rate 31.1 kHz hit rate about 60MHz/cm2

[image: hitmap_m0002_pyxar_janhoss] https://cloud.githubusercontent.com/assets/5728495/4480474/c00dfe8a-4997-11e4-8b56-be33a20e9346.png

Jan told me the core of software is the same as pxar, so it much be something in the upper level of software has trouble taking module data for xray.

Cheers, Rong-Shyang

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230.

[rslu]

HI Urs, I drew from Xray/hMap_W_C%d_V0 2d histograms. I don't think it uses PHCalib, but in anyway, the GainCalibration is done and I look through all 16 chips and check they are in the valid range of ADC value for Vcal range of our interests.

Unfortunately there is no debug log. I will send you the root file, and if I have a chance to run it again, I will do it with debug.

Cheers, Rong-Shyang

[jhoss]

Stefan asked me to provide the DAC parameters I used for obtaining the hit map shown above. I post here the DACs for ROC 0, the other ROCs only differ in those DACs which are dynamically adjusted during the pretest. Since we only wanted to test the basic functionallity of recording hits, we didn't spend time on trimming the module.

DAC parameters ROC 0, as used for measuring hitmap above: 1 Vdig 6 2 Vana 121 3 Vsf 30 4 Vcomp 12 7 VwllPr 60 9 VwllSh 60 10 VhldDel 250 11 Vtrim 29 12 VthrComp 59 13 VIBias_Bus 1 14 Vbias_sf 6 15 VoffsetOp 85 17 VOffsetR0 220 18 VIon 128 19 Vcomp_ADC 100 20 VIref_ADC 56 21 VIbias_roc 150 22 VIColOr 10 25 Vcal 200 26 CalDel 138 253 CtrlReg 0 254 WBC 100

[thweiler]

Hi, I run Daqtest and daqrun (from the highrate test folder), using Jan's parameters and the parameters genrated by mkConfig. For both set of parameters the hit map looks similar, see plots below. I saw the missing columns also with monochromatic light from X-ray tube and electrons from 90Sr source and on single chip assemblies with digV2.

DaqTest ("DAQ","hits"): mkCongif: Parameters from Jan:

Daqrun ("HighRate","hitMap_daqbbtest"): mkConfig: Parameters from Jan:

cheers Thomas

[simonspa]

Running both @jhoss's test and @ursl's test with verbosity -v DEBUGHAL could reveal differences in the algorithms. I can have a look if you post the logs here or elsewhere.

[thweiler]

Hi Simon I put the log files on the web.

RunDaqTest (HighRateTest): http://ikcms02.fzk.de/weiler/RunDaqTest_Sr90.log DaqTest: http://ikcms02.fzk.de/weiler/DaqTest_Sr90.log

cheers Thomas

May be I should add here that this happens only for digv2 chips, at least for the single chip assemblies with digv21 everything is fine also with DaqTest.

[ursl]

Hi Thomas,

many thanks for your helpful information. I have the impression, also considering your email, that the primary difference between the two cases is the difference in the argument passed into setTrgFrequency(). This results in a considerable difference in clk delays. For the working setup the pg looks like

delay 255 delay 255 delay 255 delay 255 delay 255 delay 255 delay 255 delay 165 trg 50 tok 0

while for the other two cases it is

delay 255 delay 125 trg 20 tok 0

There is a lot of potential to unify the code among the three classes PixTestDAQ, PixTestHighRate, and PixTestXray. More tomorrow.

Cheers, --U.

On Tue, Oct 14, 2014 at 11:58 AM, Thomas Weiler notifications@github.com wrote:

Hi Simon I put the log files on the web.

RunDaqTest (HighRateTest): http://ikcms02.fzk.de/weiler/RunDaqTest_Sr90.log DaqTest: http://ikcms02.fzk.de/weiler/DaqTest_Sr90.log

cheers Thomas

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230#issuecomment-59016703.

[ursl]

HI Thomas and Rong-Shyang,

I just pushed the simplest fix. If possible, could you please test whether PixTestDaq and PixTestXray now work as well? If I understood correctly, PixTestHighRate was working all the time.

Many thanks.

Cheers, --U.

On Tue, Oct 14, 2014 at 6:08 PM, Urs Langenegger urs.langenegger@psi.ch wrote:

Hi Thomas,

many thanks for your helpful information. I have the impression, also considering your email, that the primary difference between the two cases is the difference in the argument passed into setTrgFrequency(). This results in a considerable difference in clk delays. For the working setup the pg looks like

delay 255 delay 255 delay 255 delay 255 delay 255 delay 255 delay 255 delay 165 trg 50 tok 0

while for the other two cases it is

delay 255 delay 125 trg 20 tok 0

There is a lot of potential to unify the code among the three classes PixTestDAQ, PixTestHighRate, and PixTestXray. More tomorrow.

Cheers, --U.

On Tue, Oct 14, 2014 at 11:58 AM, Thomas Weiler notifications@github.com wrote:

Hi Simon I put the log files on the web.

RunDaqTest (HighRateTest): http://ikcms02.fzk.de/weiler/RunDaqTest_Sr90.log DaqTest: http://ikcms02.fzk.de/weiler/DaqTest_Sr90.log

cheers Thomas

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230#issuecomment-59016703.

[rslu]

I pulled the head this morning and took two runs with same setting and immediately one after the other (not restarting pxar). Both 200seconds, I guess rundaq is 20kHz and I set phrun to 50kHz. HighRate/rundaq Xray/phrun

[thweiler]

Hi Urs Same for me, HighRate/Rundaq works, Daq and X-ray test show still empty columns.

cheers Thomas

[ursl]

Hi Thomas and Rong-Shyang,

many thanks for your testing.

Did you use the default trigger frequencies or did you use the same? I think by default the (working) HighRate uses 20kHz, while the other two use 100 kHz.

Cheers, --U.

On Wed, Oct 15, 2014 at 10:08 AM, Thomas Weiler notifications@github.com wrote:

Hi Urs Same for me, HighRate/Rundaq works, Daq and X-ray test show still empty columns.

cheers Thomas

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230#issuecomment-59171289.

[rslu]

I use 50kHz for phrun and default of rundaq.

[thweiler]

Hi Urs I used 100kHz for all test; cheers Thomas

[simonspa]

I found this very suspicious line in PixTestXRay.cc that should be removed:

if (fParDelayTBM) fApi->setTbmReg("delays", 0x40);

the DUT setup should be finished before the test and reflect the config files. Resetting some carefully chosen TBM delays in one test can lead to invalid or no readout.

Having said that, fParDelayTBM seems to default to false, so that's probably not the culprit here.

[ursl]

This "very suspicious" line was introduced by Robert because of "Fpix timing". It is not active, at least by default. I would hope that nobody clicked the checkbox to turn it on.

On Wed, Oct 15, 2014 at 11:51 AM, simonspa notifications@github.com wrote:

I found this very suspicious line in PixTestXRay.cc that should be removed:

if (fParDelayTBM) fApi->setTbmReg("delays", 0x40);

the DUT setup should be finished before the test and reflect the config files. Resetting some carefully chosen TBM delays in one test can lead to invalid or no readout.

Having said that, fParDelayTBM seems to default to false, so that's probably not the culprit here.

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230#issuecomment-59182256.

[thweiler]

No the check box (tbm delay) was not clicked for any of the tests shown here.

[MDallOsso]

Hi everybody, sorry if I did not reply earlier but I was on vacations. I took a look at the code and I think that there was an excessive call of 'ProcessData()' both in PixTestDaq and PixTestXray. That function was called even when the buffer was not almost full and the daq was not halted. I do not have possibility to test with xray, sorry. Can you check if the situation is better now?

Thanks Martino

[thweiler]

Hi Martino The problem with the empty columns is still there. cheers Thomas

[MDallOsso]

Hi Thomas, another attempt can be (to align with the HighRate code) to try to move 'gSystem->ProcessEvents();' from line 385 to line 377.

thanks Martino

[thweiler]

Hi Martino Still the same, does not help for the empty columns. cheers Thomas

[rslu]

While trying to understand the pxar source code and api function, I did some playing of the code and found that. If I add in front of line 295 of PixelTestXray.cc

fApi->_dut->testAllPixels(false); <----- add this fApi->_dut->maskAllPixels(false); <----- add this

fPg_setup.push_back(make_pair("resetroc", 0));

I can get xray map of full module with "Xray:phrun" function without dropping double column. I guess it means the modules are not properly enabled?

[ursl]

Hi Rong-Shyang,

this may indeed be the resolution of this (in PixTestHighRate everything is enabled by default, as the intention there is to mask autonomously hot pixels). The present situation is certainly not by accident as it is, as the present setup allows for disabling hot pixels and it takes a "picture" with the detector how it is configured. However, it is not straightforward to enable the entire detector explicitly (without running, e.g. a PixelAlive::aliveTest() beforehand) test. In particular, the final solution will need to allow for hot pixels or other explicitly masked pixels.

Cheers, --U.

On Mon, Oct 20, 2014 at 3:40 PM, rslu notifications@github.com wrote:

While trying to understand the pxar source code and api function, I did some playing of the code and found that. If I add in front of line 295

fApi->_dut->testAllPixels(false); <----- add this fApi->_dut->maskAllPixels(false); <----- add this

fPg_setup.push_back(make_pair("resetroc", 0));

I can get xray map of full module with "Xray:phrun" function without dropping double column. I guess it means the modules are not properly enabled?

— Reply to this email directly or view it on GitHub https://github.com/psi46/pxar/issues/230#issuecomment-59755115.

[MDallOsso]

Hi Rong-Shyang, in the PixTestDaq there is no 'testAllPixels' call. Can you please try to do a PixTestDaq after a PixelAlive? Later can you also try to add those two lines in PixTestDaq (i.e. in line 318) and try it again?

Thanks Martino

[rslu]

Hi Martino, I did the following test

• start pxar and run PixelTestDaq (DAQ tab) -> broken map with missing double columns in all ROCs
• start pxar; run PixelAlive, run DAQ -> broken map with missing DCs
• adding testAllPixel(false) maskAllPixel(false) before line 318. start pxar and run DAQ -> complete map, no missing DC.

[MDallOsso]

good! I have just copied the Urs' changes with the two lines added (cf1a84cf56a2d982c084d07a6db7ab3d2379b15d). We will try to level the three code (high rate, xray, daq) in order to have an easier future debugging.

Martino

[ursl]

Please try again. The code now explicitly unmasks all pixels and then applies the mask file (and possibly hot pixels, if desired).

[thweiler]

Hi, Now the hit maps of all three tests (DAQ, Highrate/rundaq and X-ray) look fine on a full module.

cheers Thomas

[MDallOsso]

good! I've just commited a renew PixTestDaq. There are no substancial changes so I guess that it works fine as before. I have just added parameters and try to reorder the code and uniform it with xraytest. On monday I will commit final changes and then I will ask you to do a quick check.

Thank you, Cheers Martino