 Thu Apr 30 17:24:57 2020, Dinko Ferencek, Software, MoReWeb empty DAC plots
|
| Matej Roguljic wrote: | Some of the DAC parameters plots were empty in the production overview page. All the empty plots had the number "35" in them (e.g. DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we decided to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50.
The places where I made changes:
- Analyse/AbstractClasses/TestResultEnvironment.py
'trimThr':35
- Analyse/Configuration/GradingParameters.cfg.default
trimThr = 35
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
TrimThresholds = ['', '35']
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
self.SubPages.append({"InitialAttributes" : {"Anchor": "DACDSpread35", "Title": "DAC parameter spread per module - 35"}, "Key": "Section","Module": "Section"})
It's interesting to note that someone had already made the change in "Analyse/Configuration/GradingParameters.cfg" |
As far as I can remember, the changes in Analyse/AbstractClasses/TestResultEnvironment.py, Analyse/Configuration/GradingParameters.cfg.default and Analyse/Configuration/GradingParameters.cfg were there from before, probably made by Andrey. It is possible that you looked at the files when I was preparing logically separate commits affecting the same files which required temporarily undoing and later reapplying some of the changes to be able to separate the commits. The commits are now on GitLab https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commits/L1replacement, specifically:
435ffb98: grading parameters related to the trimming threshold updated from 35 to 50 VCal units
1987ff18: updates in the production overview page related to a change in the trimming threshold |
|
Thu Apr 30 17:33:04 2020, Andrey Starodumov, Software, MoReWeb empty DAC plots
|
| Matej Roguljic wrote: | Some of the DAC parameters plots were empty in the total production overview page. All the empty plots had the number "35" in them (e.g. DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we decided to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50.
The places where I made changes:
- Analyse/AbstractClasses/TestResultEnvironment.py
'trimThr':35
- Analyse/Configuration/GradingParameters.cfg.default
trimThr = 35
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
TrimThresholds = ['', '35']
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
self.SubPages.append({"InitialAttributes" : {"Anchor": "DACDSpread35", "Title": "DAC parameter spread per module - 35"}, "Key": "Section","Module": "Section"})
It's interesting to note that someone had already made the change in "Analyse/Configuration/GradingParameters.cfg" |
I have changed
1)StandardVcal2ElectronConversionFactorfrom 50 to 44 for VCal calibration of PROC600V4 is 44el/VCal
2)TrimBitDifference from 2 to -2 for not to take into account failed trim bit test that is an artifact from trimbit test SW. |
|
Thu May 7 00:10:15 2020, Dinko Ferencek, Software, MoReWeb empty DAC plots
|
| Andrey Starodumov wrote: |
| Matej Roguljic wrote: | Some of the DAC parameters plots were empty in the total production overview page. All the empty plots had the number "35" in them (e.g. DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we decided to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50.
The places where I made changes:
- Analyse/AbstractClasses/TestResultEnvironment.py
'trimThr':35
- Analyse/Configuration/GradingParameters.cfg.default
trimThr = 35
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
TrimThresholds = ['', '35']
- Analyse/OverviewClasses/CMSPixel/ProductionOverview/ProductionOverviewPage/ProductionOverviewPage.py
self.SubPages.append({"InitialAttributes" : {"Anchor": "DACDSpread35", "Title": "DAC parameter spread per module - 35"}, "Key": "Section","Module": "Section"})
It's interesting to note that someone had already made the change in "Analyse/Configuration/GradingParameters.cfg" |
I have changed
1)StandardVcal2ElectronConversionFactorfrom 50 to 44 for VCal calibration of PROC600V4 is 44el/VCal
2)TrimBitDifference from 2 to -2 for not to take into account failed trim bit test that is an artifact from trimbit test SW. |
1) is committed in 74b1038e.
2) was made on Mar. 24 (for more details, see this elog) and is currently left in Analyse/Configuration/GradingParameters.cfg and might be committed in the future depending on what is decided about the usage of the Trim Bit Test in module grading
$ diff Analyse/Configuration/GradingParameters.cfg.default Analyse/Configuration/GradingParameters.cfg
45c45
< TrimBitDifference = 2.
---
> TrimBitDifference = -2.
There were a few other code updates related to a change of the warm test temperature from 17 to 10 C. Those were committed in 3a98fef8. |
 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 |
|
Sun Feb 9 18:36:13 2020, Dinko Ferencek, Module grading, Manual grading
|
The procedure for manual grading is described in https://github.com/psi46/MoReWeb/pull/120.
In short, inside the test folder it is necessary to place a text file called grade.txt that contains just one number representing the manual grade:
1=A
2=B
3=C
Addendum:
It appears that manual grading does not work properly if one reruns MoReWeb with grade.txt added. It is necessary to first delete any entries related to the FullQualification using the following command
python Controller -d
after which you need to specify for which module you want to delete entries, e.g. M1537. Once done, you need to run MoReWeb for this module, e.g.
python Controller -m M1537 |
|
Fri Sep 18 15:45:21 2020, Andrey Starodumov, Other, M2211 and M2122
|
I made a mistake and instead M2122 used ID M2211 in the .ini file.
Hence now we do not have entry for M2122 but have 2 entries for M2211: one is of Sept 18 and another one called old of Sep 17).
Test results of Sep 17 are for 2211
Test results of Sep 18 are for 2122
To be corrected later |
|
Mon May 4 15:28:14 2020, Andrey Starodumov, General, M1660
|
M1660 is taken from gel-pak and cabled for retest.
This module was graded C only at second FT at-20C, the first FT at -20C and FT at +10C give grade B. Massive trimming failure of pixels in ROC7 was not observed.
The module will be retested. |
|
Fri Apr 3 17:39:19 2020, Andrey Starodumov, Module doctor, M1654
|
After a protection cap glued to M1654, I observed a few strongly bent wire bonds and probably some shorts on ROC8. One (VD+) of them is even detached (on HDI side). Pads from 25/26 till 35 are affected.
Nevertheless the Reception test gave the same results as before the cap gluing: grade A.
It would be useful if Wolfram take a look and decide what to do. Silvan proposed to remove cap and repair wire-bonds.
I could test the procedure on a dummy module (I have one) with glued cap and, if successful, do the same with M1654.
For the moment the module is placed in Module doctor tray. |
|
Fri Apr 3 13:55:48 2020, Andrey Starodumov, Reception test, M1653 failed Reception
|
Roc12-15 are not programmable.
Visual inspection is Ok, nothing found.
To module doctor! |
|
Thu Apr 2 17:06:19 2020, Andrey Starodumov, Reception test, M1652 failed Reception
|
ROC1 of M1652 is not programmable.
Put in the "Bad" tray as C module. |
|
Wed Apr 1 14:36:37 2020, Andrey Starodumov, Reception test, M1646 failed Reception
|
M1646 showed Idig=1A, ROC6 is not programmable.
Visual inspection: scratch on a periphery (between bonding pads) of ROC6.
To module doctor! |
|
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. |
|
Fri Mar 27 17:27:09 2020, Andrey Starodumov, Reception test, M1635 failed Reception
|
All ROCs are programmable but DESER400 trailer error bits: "NO DATA" or "IDLE DATA".
ROC8-11 are affected (no data)
Visual inspection is OK
To module doctor |
|
Thu Apr 30 15:38:43 2020, danek kotlinski, Module transfer, M1635 & M1671 transferred to gel-pack
|
| Two bad modules have been placed in gel-packs: 1635 & 1671. |
|
Fri Mar 27 14:28:14 2020, Andrey Starodumov, Reception test, M1633 failed Reception
|
All ROCs are programmable but permanent DESERALISER ERROR, Ch6 and Ch7 event ID mismatch.
Visual inspection is OK
To module doctor |
|
Tue Apr 14 16:54:31 2020, Andrey Starodumov, Other, M1633 cable disconnected
|
We do not have any more module holders.
M1633 was in "Module doctor" tray.
I took module off the holder and put it in a gel-pak. |
|
Fri May 29 13:56:35 2020, Andrey Starodumov, Re-grading, M1630
|
In ROC1 of M1630 gain calibration failed massively (3883 pixels) at +10C with CtrlReg 9.
A special test of M1630 only at +10C and with CtrlReg 17 showed no problem.
p10_1 from ~/L1_DATA/ExtraTests_ToBeKept/M1630_FullTestp10_2020-04-17_15h54m_1587131688/000_Fulltest_p10
copied to ~/L1_DATA/M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
and original files from ~/L1_DATA/M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
copied to ~/L1_DATA/ExtraTests_ToBeKept/p10RemovedFrom_M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
This is done to have a clean ranking of modules based on # of defects. |
|
Tue Mar 24 16:08:58 2020, Andrey Starodumov, Reception test, M1625 failed Reception
|
M1625: all ROCs are programmable but no readout from ROC0-ROC3.
The same symptom as for M1623.
Visual inspection is OK.
To module doctor. |
|
Tue Mar 24 15:20:18 2020, Andrey Starodumov, Reception test, M1623 failed Reception
|
M1623: all ROCs are programmable but no readout from ROC0-ROC3.
Visual inspection is OK.
To module doctor. |
|
Tue Mar 24 15:18:59 2020, Andrey Starodumov, Reception test, M1621 failed Reception
|
| On M1621 ROC8 is not programmable. |