| ID |
Date |
Author |
Category |
Subject |
|
295
|
Wed Jul 29 17:19:43 2020 |
danek kotlinski | PhQualification | Change configuration for PH qialification |
Preparing the new PH optimization I had to make the following modifications:
1) in elCommandante.ini
change ModuleType definition from tbm10d to tbm10d_procv4
in order to use CtrlReg=17 setting
2) in pxar/data/tbm10d_procv4
change in all dacParameter*.dat files Vsh setting from 8 to 10.
I hope these are the right locations.
D. |
|
304
|
Fri Oct 23 13:33:04 2020 |
danek kotlinski | Module transfer | L1 & L2 modules to go to P5 |
The following modules will be transported to CERN/P5 as spares.
1) L1
1538
1542
1608
1613
also take a D (broken) module 1671 for setup testing.
2) L2
2278
2160
2258
2293
2078
2026
2122
2155
2035
2036
2298
2244
2269 was at the top of Andrey's list but I just discovered that it does not have the cap,
so we leave it at PSI.
D.K. |
|
305
|
Fri Nov 6 07:28:42 2020 |
danek kotlinski | POS | POS configuration files created |
| Dinko Ferencek wrote: | pXar parameter files were converted to POS configuration files by executing the following commands on the lab PC at PSI
cd /home/l_tester/L1_SW/MoReWeb/scripts/
python queryModuleLocation.py -o module_locations.txt -f
python prepareDataForPOS.py -i module_locations.txt -p /home/l_tester/L1_DATA/ -m /home/l_tester/L1_DATA/WebOutput/MoReWeb/FinalResults/REV001/R001/ -l /home/l_tester/L1_DATA/POS_files/Folder_links/
cd /home/l_tester/L1_SW/pxar2POS/
for i in `cat /home/l_tester/L1_SW/MoReWeb/scripts/module_locations.txt | awk '{print $1}'`; do ./pxar2POS.py -m $i -T 50 -o /home/l_tester/L1_DATA/POS_files/Configuration_files/ -s /home/l_tester/L1_DATA/POS_files/Folder_links/ -p /home/l_tester/L1_SW/MoReWeb/scripts/module_locations.txt; done
The POS configuration files are located in /home/l_tester/L1_DATA/POS_files/Configuration_files/ |
Dinko
I have finally looked more closely at the file you have generated. They seem fine exept 2 points:
1) Some TBM settings (e.g. pkam related) differ from P5 values.
This is not a problem since we will have to adjust them anyway.
2) There is one DAC setting missing.
This is DAC number 13, between VcThr and PHOffset.
This is the tricky one because it has a different name in PXAR and P5 setup files.
DAC 13: PXAR-name = "vcolorbias" P5-name="VIbias_bus"
its value is fixed to 120.
Can you please insert it.
D. |
|
87
|
Mon Feb 24 13:53:32 2020 |
Urs Langenegger | Module assembly | Setup changes in week 8 |
Setup changes in week 8
Silvan considered the single-module gluing approach suboptimal. It was changed:
- we switched sides, the cap gluing is now done on the window-side of the aisle
- there are now two jigs set up for cap gluing
The procedure itself for gluing did not change: Apply the stamp with the glue to module 1, release, put module 1 into its jig, insert module 2 into gluing jig, apply stamp (because of the glue fluidity, the marks from module 1 will have disappeared and there is no need to re-apply any glue to the stamp). The caps are lowered onto the modules only once the glue has been applied to both modules.
Silvan recommended applying the weight of only one copper(?) bar, to be placed centered on the top of the z-stage.
Silvan also recommended against using ethanol. Instead we are supposed to use aceton. As a result, the plastic tweezers should not be used anymore, but rather metallic tweezers.
Finally, Silvan changed the Peltiers, and applied isolation inside Red October. We observed cooling times from 10C to -20C of 6 minutes. |
|
88
|
Mon Feb 24 14:01:29 2020 |
Urs Langenegger | Module assembly | Cap gluing in W8 |
In week 8 the following modules were glued and tested:
M1581
M1582
M1583
M1584
M1585
M1586
M1587
M1588
M1589
M1591
M1590 was not glued last week because it had one HV bond broken (Silvan fixed this on Monday, 20/02/24).
M1586 initially had problems with the readout after gluing, but this was fixed by porperly closing the MOLEX connector. In the reception test, M1586 was graded 'B'.
All other modules were graded 'A' in the reception test.
Overall the double-gluing setup works very well. The modules above were glued basically in one day. |
|
89
|
Tue Feb 25 17:11:18 2020 |
Urs Langenegger | Module assembly | Modules glued and tested Feb 24/25 |
Modules glued and tested Feb 24/25
The letters after the module name indicate the reception test grade.
M1590 A (after Silvan fixed broken HV bond)
M1592 A
M1595 B
M1596 A
M1597 A
M1599 C (leakage current: 16uA)
M1600 A
M1598 had a broken clock wire bond, was diagnosed by Wolfram and fixed by Silvan. Will be processed together with the other modules that had problems after taking them out of the storage box (M1593 and M1594), in case they can be fixed. |
|
90
|
Wed Feb 26 10:34:55 2020 |
Urs Langenegger | Full test | Fulltest after Peltier replacement |
On 2020/02/25, after SIlvan had replaced the Peltiers, I did a fulltest. Here the summary:
Finished all tests. Summary of test durations:
Fulltest@-20 127 min 5 sec
IV_TB0@-20 4 min 23 sec
IV_TB1@-20 5 min 1 sec
IV_TB2@-20 5 min 1 sec
IV_TB3@-20 5 min 1 sec
Cycle 39 min 23 sec
Fulltest@-20 121 min 6 sec
IV_TB0@-20 4 min 23 sec
IV_TB1@-20 5 min 1 sec
IV_TB2@-20 5 min 1 sec
IV_TB3@-20 5 min 1 sec
Fulltest@10 115 min 17 sec
IV_TB0@10 4 min 42 sec
IV_TB1@10 5 min 5 sec
IV_TB2@10 5 min 5 sec
IV_TB3@10 5 min 5 sec
--------------------------------------------------
total 461 min 48 sec
All modules were graded 'B' (I think because of the noise mean being to high in a few chips per module) |
|
91
|
Thu Feb 27 09:47:51 2020 |
Urs Langenegger | Full test | Fulltest on 2020/02/26 |
On Wednesday, 2020/02/26 the following modules went through the full qualification procedure:
M1581
M1582
M1583
M1584
All received grade B (from a cursory glance due to mean noise). |
|
93
|
Fri Feb 28 17:33:16 2020 |
Urs Langenegger | Full test | Fulltests on 2020/02/28 |
M1589 B
M1590 C (gain issues?)
M1591 C (noise issues?)
M1592 B |
|
94
|
Mon Mar 2 17:39:36 2020 |
Urs Langenegger | Full test | Fulltests on 2020/03/02 |
Modules tested:
M1595 C
M1596 B
M1597 C
M1600 C
Andrey and I suspect that these grades are driven by a bad PH optimization. |
|
99
|
Wed Mar 11 15:34:57 2020 |
Urs Langenegger | Other | M1586: issues with MOLEX? |
Module M1586 had passed the full qualification on 20/02/27. I had had to re-insert the cable in the Molex connector for it to become programmable.
On 2020/03/09, I tried to re-test M1586, but it was not programmable. Visual inspection revealed nothing to me. I did re-insert the cable once again, but this time this did not help.
Maybe one should try again re-inserting the cable.
Maybe these issues are an indication that the module (MOLEX) is flaky. |
|
147
|
Fri Mar 27 10:54:04 2020 |
Urs Langenegger | Full test | Issues with pc11366 on March 27 |
On March 27 I had a lot of troubles getting the full qualification up
and running.
The problems were (1) strange error messages from pxar core, (2)
problems with USB connections to the DTBs, (3) loads of (intermittent)
data transmission errors from the DTBs, and (4) complaints about missing
(system) libs.
In the end I did killall firefox and (out of superstition) pkill compiz.
Then it worked again. |
|
163
|
Tue Mar 31 09:29:02 2020 |
Urs Langenegger | Full test | exchanged adapter for DTB_WXC03A |
I did not manage to get any r/o from the module connected to that adapter, also after exchanging the module.
So I exchanged the module adapter with the one from the blue box, and all issues with r/o were gone (with both modules)
Of course, the apparently flaky adapter from WXC03A seems to be working again/now in the blue box.
Just fyi. |
|
164
|
Tue Mar 31 10:32:32 2020 |
Urs Langenegger | Full test | M1637 |
Maybe M1637 has an issue: It got stuck twice at the same place with
[09:53:16.043] <TB0> INFO: PixTestReadback::CalibrateIa()
[09:53:16.043] <TB0> INFO: ----------------------------------------------------------------------
[09:53:17.924] <TB0> ERROR: <datapipe.cc/CheckEventID:L486> Channel 6 Event ID mismatch: local ID (22) != TBM ID (23)
[09:53:17.924] <TB0> ERROR: <hal.cc/daqAllEvents:L1701> Channels report mismatching event numbers: 23 22 22 22 22 22 22 22
After that, the DTB is unresponsive and elCommandante loses it. (The printout above is from the second testrun. I had restarted the complete fullqualification after realizing that DTB0 was 'missing' and checking manually that M1637 was properly connected).
I hope elCommandante manages this gracefully. |
|
167
|
Tue Mar 31 17:36:36 2020 |
Urs Langenegger | Full test | exchanged adapter for DTB_WXC03A |
| Urs Langenegger wrote: | I did not manage to get any r/o from the module connected to that adapter, also after exchanging the module.
So I exchanged the module adapter with the one from the blue box, and all issues with r/o were gone (with both modules)
Of course, the apparently flaky adapter from WXC03A seems to be working again/now in the blue box.
Just fyi. |
Today I have to reconnect a few times modules to the module adapter in the blue box.
It looks like the Molex connector is a bit damaged. One should be very careful while connecting a cable to this Molex connector. |
|
237
|
Wed Apr 29 08:48:06 2020 |
Urs Langenegger | Other | M1539 |
M1539 showed no readout. I tried, all without success,
- reconnecting the cable to the adapter multiple times
- connecting to the adapter in the blue box
- reconnecting the cable to the MOLEX on the module |
|
294
|
Fri Jul 10 11:24:37 2020 |
Urs Langenegger | Reception test | proc600V3 modules |
This week I tested 12 modules built with proc600v3. The module numbers are M1722 - M1733.
The results are summarized at the usual place:
http://cms.web.psi.ch/L1Replacement/WebOutput/MoReWeb/Overview/Overview.html
Cheers,
--U. |
|
143
|
Thu Mar 26 15:37:18 2020 |
Urs | Module grading | M1606 |
| attached find the threshold difference distributions for all four trimbits for all ROCs |
| Attachment 1: anaTrim-thrDiff-data__M1606__pxar.pdf
|
|
|
157
|
Mon Mar 30 15:40:52 2020 |
Urs | Full test | FT of M1629, M1630, M1631, M1632 |
M1630 is interesting because (I am using my terminology in the following) for the test at T=+10C ROC1 fails the PH optimization test and by consequence the gain/pedestal test is also failed.
The PH optimization test is failed because the minimum pixel on which the test is based is a 'dead' pixel (according to the PixelAlive test), but unfortunately has hits in the initial PH map. As a result the phscale and phoffset for this ROC are not optimal and this is seen in the gain/pedestal fits.
Please find the plots attached from the T=+10 tests. |
| Attachment 1: phval-curve_M1630_p10_C1.pdf
|
|
| Attachment 2: phshot_vcal255.pdf
|
|
| Attachment 3: pixelalive_C1.pdf
|
|
|
2
|
Tue Aug 6 15:15:00 2019 |
Matej Roguljic | General | Activities 19.6.-4.7.2019. |
17.6.-21.6.
Andrei and Matej were at PSI working on the cap gluing setup
Andrei cap glued M2029 (Box9,T110)
Matej cap glued M2331
M2331 was tested before and after cap gluing
M2233 was taken to Zagreb for irradiatio, cable of the mdule is in Box4, T040
1.7.
HDIs 3019 and 3020 were tested and both failed, results in the HDIresults
Performed characterization on one v4 chip, it will be irradiated in Zagreb and restested
2.7.
Silvan bonded the M1520 so Andrei and Matej performed full qualification on it (-20 and +10) and it took 5 hours
3.7.
Glued caps on 3 dummy modules with 3 different glues.
HDI 1317-3-008 with two component epoxy glue
HDI 1317-3-010 with SG-20 silicon glue
HDI 1317-3-004 with WS-200 silicon glue
4.7.
3 dummy modules taken to Zagreb for irradiation by Matej
M1508 was also taken |