Skip to content
This repository has been archived by the owner on Jan 31, 2022. It is now read-only.

Redefine the goal of testConnectivity.py #287

Open
1 of 2 tasks
lpetre-ulb opened this issue Nov 7, 2019 · 1 comment
Open
1 of 2 tasks

Redefine the goal of testConnectivity.py #287

lpetre-ulb opened this issue Nov 7, 2019 · 1 comment

Comments

@lpetre-ulb
Copy link
Contributor

Brief summary of issue

Last week, issues related to incorrectly setting the IREF values were discovered at QC7. After a more detailed study (thanks Nimantha!) and a code review different issues were found.

This issue aim at improving the correctness, robustness and efficiency of testConnectivity.py by redefining its purpose.

Types of issue

  • Bug report (report an issue with the code)
  • Feature request (request for change which adds functionality)

Issues found

  1. Incorrect IREF configuration for the Scurves taken during testConnectivity.py
  2. confChamber.py is not guaranteed to configure the chamber in the same way as testConnectivity.py
  3. DB access mandatory; if VFAT without Reed-Muller encoded chipID are used, the calibration constants can be retrieved for the wrong VFAT in case of bitflip
  4. VFATs missing in DB seems not to be properly reported
  5. The analysis of the Scurves taken during testConnectivity.py does not produce any output; they must be analyzed a second time to get the plots

Expected Behavior/Proposal

Historically, testConnectivity.py was designed to make the pass/failed decision about on the quality control of a chamber during QC7. However, the QC7 tests were improved and complexed over time leading to other scripts doQC7.sh and doQC7_complete.sh, both using testConnectivity.py.

Considering this, below is a list of changes we agreed on with Nimantha. They would fulfill all the requirements of QC7 and remote tests stands without VFAT3 hybrid v3 and/or DB access.

In summary, testConnectivity.py must be able to completely prepare a new chamber on every test stands while ensuring that confChamber.py correctly configure the chamber. After the chamber configuration, all acquisitions must run in the best conditions.

  1. Whenever the DAC scans are successful, all DAC values - including IREF so - must be written to the CTP7.
  2. Instead of modifying the chamber configuration on the fly, testConnectivity.py should warn that the VFAT configuration does not use the recommended values. This should ensure that confChamber.py will configure the chamber in the same way as testConnectivity.py while allowing for experimentation with different parameters.

try:
args.run = False # will be placed into run mode by the call of launchSCurve below
configure(args, vfatBoard)
# Ensure Gain is Medium
vfatBoard.parentOH.broadcastWrite("CFG_RES_PRE",0x2,dict_vfatMask[ohN])
vfatBoard.parentOH.broadcastWrite("CFG_CAP_PRE",0x1,dict_vfatMask[ohN])
# Ensure Comp Mode is CFD
vfatBoard.parentOH.broadcastWrite("CFG_PT",0xf,dict_vfatMask[ohN])
vfatBoard.parentOH.broadcastWrite("CFG_FP_FE",0x7,dict_vfatMask[ohN])
vfatBoard.parentOH.broadcastWrite("CFG_SEL_COMP_MODE",0x0,dict_vfatMask[ohN])
vfatBoard.parentOH.broadcastWrite("CFG_FORCE_EN_ZCC",0x0,dict_vfatMask[ohN])

  1. Provide a DB (default) and non-DB mode (--noDB flag):
  • In non-DB mode, zero DB access is made. The the information must have been retrieved from the DB before launching (through a first call to testConnectivity.py or through getCalInfoFromDB.py) or manually (for experimentation and/or VFAT3 hybrid v2).
  • In DB mode, all the information is always retrieved from the DB. No missing VFAT is allowed. If it was to happen, the user can use getCalInfoFromDB.py first.
  1. Remove the Scurve acquisition from the testConnectivity.py script. The acquisition and analysis can be added to doQC7.sh or to doQC7_complete.sh (only on the the QC7 DAQ machine) for easy QC7 operation.

Your Environment

@jsturdy
Copy link
Contributor

jsturdy commented Nov 8, 2019

Before anyone starts putting significant effort into this, let me stress that this change should be made post migration of framework.
If there is effort floating around wanting to work on the task in this issue, it should be redirected to ensuring that the migration is completed first.

AndrewLevin pushed a commit to AndrewLevin/vfatqc-python-scripts that referenced this issue May 19, 2020
…bit_thresh_zero_issue

Search for sbit rate = 100 from high to low instead of low to high

Closes cms-gem-daq-project#286
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants