cms-gem-daq-project/vfatqc-python-scripts

sbit rate inverse on VFAT. Bug on the sbintMapNRate scan - scanLog.log file is empty

Closed this issue · 2 comments

ChristosRos commented

Brief summary of issue

Yesterday we realised that on one VFAT8 from OH10 the sbit rate was inverted with respect to the rest of VFATs of the other 2 chambers we were using (OH2 and OH3) where with the same configuration had normal sbit rate. We tried to investigate the problem by making an sbitMapNRate scan.
As gemuser we ran the command:
[gemuser@gem904qc8daq ~]$ run_scans.py sbitMapNRate -r 1000 -t 1000 eagle35 0x400

Open pickled address table if available /opt/cmsgemos/etc/maps//amc_address_table_top.pickle...
Initializing AMC eagle35
opened connection
Checking SBIT Mapping for OH10 detector GE11-X-S-BARI-0006
22 Feb 2019 09:24:25.464 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: mkdir -p /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//2019.02.22.09.24
22 Feb 2019 09:24:25.533 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: chmod g+rw /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//2019.02.22.09.24
22 Feb 2019 09:24:25.556 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: unlink /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//current
22 Feb 2019 09:24:25.591 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: ln -s 2019.02.22.09.24 /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//current
22 Feb 2019 09:24:25.614 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: checkSbitMappingAndRate.py --cardName=eagle35 -f /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//2019.02.22.09.24/SBitMappingAndRateData.root -g 10 --nevts=100 --rates=1000 --time=1000 --vfatmask=0x1 --voltageStepPulse
22 Feb 2019 09:27:10.662 [7f0e263fe740] INFO - wrappers::runCommand <> - Executing command: chmod -R g+rw /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//2019.02.22.09.24
Finished Checking SBIT Mapping for OH10 detector GE11-X-S-BARI-0006
Finished Checking SBIT Mapping for all optohybrids in ohMask: 0x400
Good-bye

Types of issue

While we access the output on the directory " /data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-X-S-BARI-0006/sbitMonitor/intTrig//2019.02.22.09.24"
and checking the scanLog.log file we see the following log:
"
019.02.22.09.24
Open pickled address table if available /opt/cmsgemos/etc/maps//amc_address_table_top.pickle...
Initializing AMC eagle35
opened connection
===========================Monitoring SBits Cal Pulse DISABLED===========================
Caught an error: Writing masked reg failed due to reading problem
Caught an error: Writing masked reg failed due to reading problem
Traceback (most recent call last):
File "/opt/cmsgemos/bin/checkSbitMappingAndRate.py", line 171, in
raise Exception('RPC response was non-zero, checking sbit mapping for vfat %i failed'%vfat)
Exception: RPC response was non-zero, checking sbit mapping for vfat 1 failed "

Expected Behavior

While executing the command to do and sbitMapNRate we expect to read all the VFATs from a detector and mask 3071 strips at a time leaving only one in order to check if it responds.
This steps is being repeated for all the strips of the chamber.

Current Behavior

The output of the log file:

2019.02.22.09.24
Open pickled address table if available /opt/cmsgemos/etc/maps//amc_address_table_top.pickle...
Initializing AMC eagle35
opened connection
===========================Monitoring SBits Cal Pulse DISABLED===========================
Caught an error: Writing masked reg failed due to reading problem
Caught an error: Writing masked reg failed due to reading problem
Traceback (most recent call last):
File "/opt/cmsgemos/bin/checkSbitMappingAndRate.py", line 171, in
raise Exception('RPC response was non-zero, checking sbit mapping for vfat %i failed'%vfat)
Exception: RPC response was non-zero, checking sbit mapping for vfat 1 failed "

  • Reading problem.

Steps to Reproduce (for bugs)

Possible Solution (for bugs)

Context (for feature requests)

We do not understand why this inversion on VFAT8, OH10 happened with respect to the other OHs (OH2 and OH3) and we tried to investigate by doing this sbitMapNRate

Your Environment

  • Version used:
  • Shell used: logged in as "gemuser" in gem904qc8daq
bdorney commented

Might want to use markdown syntax (same as used by Mattermost) to clean this up again.

Also it's not clear how to reproduce the problem, can you fill out the section on:

Steps to Reproduce (for bugs)

cgalloni commented

this seems not relevant anymore