CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, Page 5 of 16  Not logged in ELOG logo
Entry  Wed Oct 2 12:50:52 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification 
Full qualification was attempted for M1532 on Oct. 1. After the second Fulltest at -20 C finished, the Keitley client crashed with the following error
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
    self.check_busy(data[1:])
  File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 139, in check_busy
    if data[0] == '\x11': # XON
RuntimeError: maximum recursion depth exceeded in cmp

Because of this, the IV measurement never started (the main elComandante process was simply hanging and waiting for the Keithley client to report it's ready) and the main elComandante process had to be interrupted.
    Reply  Sat Oct 5 22:59:58 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification 
A new attempt to run the full qualification for M1532 was made on Friday, Oct. 4, but the Keithely client crashed with the same error message. This time we managed to see from log files that the crash happened after the first IV measurement at -20 C was complete and Keithley was reset to -150 V. Unfortunately, the log files were now saved for the test on Tuesday so we couldn't confirm that the crash occurred at the same point.
Entry  Wed Nov 27 18:25:08 2019, Dinko Ferencek, Software, pXar code updated 
pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.

The sequence of commands to update the code was the following:
cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install
Entry  Wed Nov 27 21:50:02 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules 
Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.

The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.

The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf

tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4
    Reply  Thu Nov 28 18:23:31 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules 

Dinko Ferencek wrote:
Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.

The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.

The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf

tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4


Since the new PH optimization code was added under the already existing PH test, the old configuration files would have to be updated to have the correct parameter values set for the expanded PH test. For this purpose, the old configuration folders were renamed

tbm10d_procv3 --> tbm10d_procv3_old
tbm10d_procv4 --> tbm10d_procv4_old

and new configuration files were re-generated from scratch

./mkConfig -d ../data/tbm10d_procv3 -t TBM10D -r proc600v3 -m
./mkConfig -d ../data/tbm10d_procv4 -t TBM10D -r proc600v4 -m

In addition, in both sets of configurations files, the configuration for the BB2 tab in the pXar GUI was moved from moreTestParameters.dat to testParameters.dat to have the BB2 tab available by default when starting pXar using these configuration files.
    Reply  Thu Nov 28 18:34:00 2019, Dinko Ferencek, Software, pXar code updated 

Dinko Ferencek wrote:
pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.

The sequence of commands to update the code was the following:
cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install


pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/9eb0f3844e9c7f98d7701629c5af339632c5d84a to pick up the latest update that allows running of the fullTest() method of each of the tests from the command line and consequently also from elComandante.
Entry  Thu Nov 28 18:58:30 2019, Dinko Ferencek, Software, Updated Fulltest configuration 
The Fulltest definition used on the lab PC and stored in /home/l_tester/L1_SW/elComandante/config/tests/Fulltest had the following content

pretest
FullTest
bb2
exit

where FullTest is defined in https://github.com/psi46/pxar/blob/9eb0f3844e9c7f98d7701629c5af339632c5d84a/tests/PixTestFullTest.cc#L82-L121. For added flexibility, we would like to have individual tests specified in the definition file. However, by default this implies calling the doTest() method for each of the tests while FullTest actually calls the fullTest() method. For Scurves and GainPedestal the two methods are distinct. After the latest updates from Urs to the pXar code, we are now able to change the definition to

pretest
readback
alive
bb
bb2
scurves:fulltest
trim
ph
gainpedestal:fulltest
exit

Note that readback was placed first because in the past it was observed that pXar had a tendency to crash when this test was run last.
Entry  Fri Nov 29 17:06:26 2019, Dinko Ferencek, General, Dropbox folder on CERNBox set up 
A dropbox folder for elComandante tar files was set up in my CERNBox and synchronized with the following local folder on the lab PC

/media/disk1/DATA/L1_DATA_Backup/CERNBox_Dropbox/

Note that the following link in the home folder

/home/l_tester/DATA

points to

/media/disk1/DATA/

so an alternative path is

/home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/

The CERNBox client was installed on the lab PC following instructions for Ubuntu at https://cernbox.cern.ch/cernbox/doc/linux.html
    Reply  Mon Jan 20 13:47:33 2020, Dinko Ferencek, Software, pXar code updated 

Dinko Ferencek wrote:

Dinko Ferencek wrote:
pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.

The sequence of commands to update the code was the following:
cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install


pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/9eb0f3844e9c7f98d7701629c5af339632c5d84a to pick up the latest update that allows running of the fullTest() method of each of the tests from the command line and consequently also from elComandante.


pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/f6e42c17c0bb3a44bdb3fa13d8f8afb6cae62a81 to pick up the latest PH optimization updates.
Entry  Mon Jan 20 21:33:20 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization TrimBitTest_old.pngTrimBitTest_new.png
We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.

We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots).
    Reply  Tue Jan 21 12:19:08 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization 

Dinko Ferencek wrote:
We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.

We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots).


The problem was traced down to a wrong value of the vcallow parameter in the PH optimization configuration. The value was 10 instead of 50 expected by the test. It turned out that the optimization converged for M1521 because this is a PROC600V3 module for which the configuration files were regenerated for another reason and vcallow was consequently set to the right value of 50. The other 3 modules are PROC600V4 modules and for them old configuration files with a wrong vcallow value were used.
Entry  Wed Jan 22 11:39:48 2020, Dinko Ferencek, Software, BB2 configuration 
When attempting to run the FullQualification this morning, pXar crashed while running the BB2 test. After some investigation, we realized the source of the problem was the BB2 configuration missing from testParameters.dat. The configuration is available in moreTestParameters.dat but by default the mkConfig script does not put it in testParameters.dat. Since we run BB2 in the FullQualification, the configuration needs to be copied by hand every time the configuration files are regenerated.
Entry  Wed Jan 22 11:50:20 2020, Dinko Ferencek, Software, Module configuration files for interactive tests 
There are two module configuration folders set up for elComandante

/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4/

These folder can also be used for interactive tests with pXar. However, in that case these folders get filled with pxar.log and pxar.root files. For some reason, elComandante when copying the module configuration files also copies all pxar.log files. To prevent unnecessary duplication of junk files, two new module configuration folders were set up for interactive tests with pXar

/home/l_tester/L1_SW/pxar/data/tbm10d_procv3_pxar/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4_pxar/

The configurations are identical to those used by elComandante. However, one needs to remember to keep the tests folders in sync with the elComandante folders once they get updated. This can be done as follows

rsync -avPSh /home/l_tester/L1_SW/pxar/data/tbm10d_procv3/ /home/l_tester/L1_SW/pxar/data/tbm10d_procv3_pxar/
rsync -avPSh /home/l_tester/L1_SW/pxar/data/tbm10d_procv4/ /home/l_tester/L1_SW/pxar/data/tbm10d_procv4_pxar/

To check if there are any extraneous pXar files present in the configuration folders, run

find /home/l_tester/L1_SW/pxar/data/tbm10d_procv?/ -type f \( -name 'pxar*.log' -o -name 'pxar*.root' \)

If any, they can be deleted by running

find /home/l_tester/L1_SW/pxar/data/tbm10d_procv?/ -type f -name \( -name 'pxar*.log' -o -name 'pxar*.root' \) -delete
Entry  Thu Jan 23 14:54:45 2020, Dinko Ferencek, Cold box tests, Keithley exchanged 
Yesterday during an attempt to run the FullQualification, elComandante would lose control over Keithley after performing the IV curve measurements and would go in the subsequent Fulltest with HV off. This happened both between the two sets of tests at -20 C and between the tests at -20 C and +10 C. Today we exchanged the old Keithley with a new one and we observe that the communication with this new Keithley is much smoother without any error codes and warning sounds produced by Keithley.

In order to properly communicate with the new Keithley, it was necessary to set its communication mode to RS-232 and BAUD rate to 57600 (https://youtu.be/-5RmguqC7xA). Everything else was left unchanged:

BITS = 8
PARITY = NONE
TERMINATOR = <CR+LF>
FLOW-CRTL = XON-XOFF
Entry  Thu Jan 23 15:15:45 2020, Dinko Ferencek, Software, Trimming Vcal value changed from 35 to 40 
Trimming Vcal value changed from 35 to 40 in the testParameters.dat files stored in

/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3_test/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4_test/

This is the value we will use for the FullQualification.
Entry  Fri Jan 24 18:12:00 2020, Dinko Ferencek, Software, MoReWeb code updates 
MoReWeb code updated to include the ROC wafer info in the XrayCalibration and XRayHRQualification pages:
https://gitlab.cern.ch/CMS-IRB/MoReWeb/commit/4de8ea39050600367ae0b8e959fcc00f29be45d8

In addition, two BB2 plots with wrong axis labels were fixed:
https://gitlab.cern.ch/CMS-IRB/MoReWeb/commit/3cfa18fc3aab1a29859ba9f0f81aa0ed4c59d5c8
https://gitlab.cern.ch/CMS-IRB/MoReWeb/commit/bb6627e6ab3f4d08eb54970a7e3d3b751983e15a
Entry  Fri Jan 24 18:16:09 2020, Dinko Ferencek, Module assembly, Protective cap gluing 
Today I additionally practiced protective cap gluing by adding a protective cap to module M1536.
Entry  Fri Jan 24 18:22:00 2020, Dinko Ferencek, General, L1 replacement web page updated 
This week several new links were added to the main L1 replacement web page located at the following URL
http://cms.web.psi.ch/L1Replacement/

The links point to other pages or information related to the replacement module qualification.
Entry  Tue Feb 4 19:35:38 2020, Dinko Ferencek, Module transfer, 7 modules prepared for transfer to ETH: 1536, 1537, 1538, 1540, 1541, 1542, 1543 
The following modules have been prepared today for transport to ETH for x-ray qualification:
1536, 1537, 1538, 1540, 1541, 1542, 1543

The FullQualification tar files for these modules have been copied to the common CERNBox folder shared with ETH.
Entry  Tue Feb 4 19:51:10 2020, Dinko Ferencek, Module assembly, Cap gluing 
Today protective caps have been glued to modules 1545, 1547, 1548, 1549, and 1550.
ELOG V3.1.3-7933898