CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, Page 6 of 16  Not logged in ELOG logo
 Find |  Login |  Help 
New entries since:Thu Jan 1 01:00:00 1970
 Full | Summary | Threaded | Hide attachments  Show all entries   Error: Attribute "Type" for quick filter not found  303 Entries 
Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 14, 15, 16   Next  All
ID Date Author Category Subjectdown
  244   Thu Apr 30 17:24:57 2020 Dinko FerencekSoftwareMoReWeb 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
  245   Thu Apr 30 17:33:04 2020 Andrey StarodumovSoftwareMoReWeb 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.
  253   Thu May 7 00:10:15 2020 Dinko FerencekSoftwareMoReWeb 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.
  53   Fri Jan 24 18:12:00 2020 Dinko FerencekSoftwareMoReWeb 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
  76   Sun Feb 9 18:36:13 2020 Dinko FerencekModule gradingManual 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
  303   Fri Sep 18 15:45:21 2020 Andrey StarodumovOtherM2211 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
  249   Mon May 4 15:28:14 2020 Andrey StarodumovGeneralM1660
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.
  183   Fri Apr 3 17:39:19 2020 Andrey StarodumovModule doctorM1654
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.
  177   Fri Apr 3 13:55:48 2020 Andrey StarodumovReception testM1653 failed Reception
Roc12-15 are not programmable.
Visual inspection is Ok, nothing found.
To module doctor!
  173   Thu Apr 2 17:06:19 2020 Andrey StarodumovReception testM1652 failed Reception
ROC1 of M1652 is not programmable.
Put in the "Bad" tray as C module.
  170   Wed Apr 1 14:36:37 2020 Andrey StarodumovReception testM1646 failed Reception
M1646 showed Idig=1A, ROC6 is not programmable.
Visual inspection: scratch on a periphery (between bonding pads) of ROC6.
To module doctor!
  164   Tue Mar 31 10:32:32 2020 Urs LangeneggerFull testM1637
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.
  152   Fri Mar 27 17:27:09 2020 Andrey StarodumovReception testM1635 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
  242   Thu Apr 30 15:38:43 2020 danek kotlinskiModule transferM1635 & M1671 transferred to gel-pack
Two bad modules have been placed in gel-packs: 1635 & 1671.
  148   Fri Mar 27 14:28:14 2020 Andrey StarodumovReception testM1633 failed Reception
All ROCs are programmable but permanent DESERALISER ERROR, Ch6 and Ch7 event ID mismatch.
Visual inspection is OK
To module doctor
  210   Tue Apr 14 16:54:31 2020 Andrey StarodumovOtherM1633 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.
  278   Fri May 29 13:56:35 2020 Andrey StarodumovRe-gradingM1630
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.
  130   Tue Mar 24 16:08:58 2020 Andrey StarodumovReception testM1625 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.
  128   Tue Mar 24 15:20:18 2020 Andrey StarodumovReception testM1623 failed Reception
M1623: all ROCs are programmable but no readout from ROC0-ROC3.
Visual inspection is OK.
To module doctor.
  127   Tue Mar 24 15:18:59 2020 Andrey StarodumovReception testM1621 failed Reception
On M1621 ROC8 is not programmable.
Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 14, 15, 16   Next  All
ELOG V3.1.3-7933898