cms-gem-daq-project / cmsgemos Goto Github PK

GEM Online Software

Makefile 6.78% Perl 0.45% JavaScript 0.92% C++ 77.43% CSS 0.30% Shell 2.50% Python 11.62%

cmsgemos's Introduction

cmsgemos

Code Status

Branch	Travis CI	Coveralls	Codecov	Codacy	Landscape	CodeClimate
master
generic-amc-release-v3
develop

Quick setup

General info

Contributing

See our contributing guide

cmsgemos's People

Contributors

Stargazers

Watchers

cmsgemos's Issues

Cannot configure the detector

confChamber.py crashes with the following error message:

2017.07.05.14.06
opened connection
Traceback (most recent call last):
  File "/home/GE11COSMICS/Software/DAQ/vfatqc-python-scripts/confChamber.py", line 42, in <module>
    biasAllVFATs(ohboard,options.gtx,0x0,enable=False)
  File "/home/GE11COSMICS/Software/DAQ/cmsgemos/gempython/tools/vfat_user_functions_uhal.py", line 247, in biasAllVFATs
    writeAllVFATs(device, gtx, "VCal",        parameters.defaultValues["VCal"       ], mask=mask)
KeyError: 'VCal'

Command line used:

confChamber.py -s2 -g0 --shelf=3 --vfatmask=0xF40400 --vt1bump=5 --chConfig=$DATA_PATH/config/chConfig.txt --vfatConfig=$DATA_PATH/config/vfatConfig.txt

Got this crash on branches generic-amc-release-v3 and generic-amc-release-v3-qc8.

Brief summary of issue

Linked to cms-gem-daq-project/ldqm-browser#13

Types of issue

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

Expected Behavior

We should use the configuration tags and pull the hardware configuration from the DB rather then query the hardware each time. A new utility taking care about new configuration tags should be added.

Migrate away from separate python functions

Need to migrate away from using the special libraries to provide functionality to the python tools.
Rather, set up gempython as directory with the test scripts and special python modules, but provide boost python bindings from the HW device classes directly
Examples exist that we are familiar with (cactus uhal, amc13, etc.)

const correctness migrations

The xdaq core software changed significantly their utilization of const in migrating from xdaq13 to xdaq14

For cc7/slc6 compatibility, attempt a rebuild utilizing appropriate const_cast and well motivated #ifdef x86_64_centos7

Bug in readout task

Some uncaught exception is occasionally happening that should be fixed so the software doesn't crash.
I haven't been able to track down where exactly it's happening, or what specifically is causing it, but something while communicating with the AMC13 during the readout is timing out

26 Oct 2016 13:17:51.439 [140699091592960] FATAL root <GEMReadoutTask> - Uncaught exception in main thread
terminate called after throwing an instance of 'uhal::exception::TcpTimeout'
  what():  Timeout (1000 milliseconds) occurred for receive from ControlHub with URI: chtcp-2.0://gem904daq01:10203?target=192.168.2.171:50001

Process [21582] on node gem904daq01.cern.ch terminates abnormally at 2016-10-26T08:17:51.443870-05:00. Caught signal 6 at address [0x8020000544e]
Stacktrace follows:
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox10stacktraceEiRSo+0x44) [0x7ff79ac82134]
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox18signalSEGVCallbackEiP7siginfoPv+0x262) [0x7ff79ac82dc2]
/lib64/libpthread.so.0() [0x304de0f7e0]
/lib64/libc.so.6(gsignal+0x35) [0x304d6325e5]
/lib64/libc.so.6(abort+0x175) [0x304d633dc5]
/usr/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x12d) [0x30542bea7d]
/opt/xdaq/lib/libtoolbox.so(+0x4a1df) [0x7ff79ac831df]
/usr/lib64/libstdc++.so.6() [0x30542bcbd6]
/usr/lib64/libstdc++.so.6() [0x30542bcc03]
/usr/lib64/libstdc++.so.6(__cxa_rethrow+0x46) [0x30542bcc86]
/opt/cactus/lib/libcactus_uhal_uhal.so(_ZN4uhal15ClientInterface8dispatchEv+0x13a) [0x7ff777b5e84a]
/opt/cactus/lib/libcactus_amc13_amc13.so(_ZN5amc1311AMC13Simple4readENS0_5BoardERKSs+0x1ea) [0x7ff7778741ca]
/home/daqbuild/build//cmsgemos/gemhardware/lib/linux/x86_64_slc6/libgemhardware.so(_ZN3gem2hw5amc1312AMC13Readout8dumpDataEv+0xfb) [0x7ff77754703b]
/home/daqbuild/build//cmsgemos/gemreadout/lib/linux/x86_64_slc6/libgemreadout.so(_ZN3gem7readout21GEMReadoutApplication11readoutTaskEv+0x1ac) [0x7ff7771e095c]
/opt/xdaq/lib/libtoolbox.so(_Z10threadFuncPv+0xcf) [0x7ff79ac9a6af]
/lib64/libpthread.so.0() [0x304de07aa1]
/lib64/libc.so.6(clone+0x6d) [0x304d6e8aad]
Aborted (core dumped)

VFAT Mask configuration

setVFATMask is not called by anyone except TBUtils. There should be a parameter in the main XML config and corresponding setter call

Bug Report: Infinite Loop in getUltraScanResults(...)

Brief summary of issue

When taking threshold scans with vfatqc-python-scripts/ultraThreshold.py it looks like an inifinite loop in getUltraScanResults(...) occurs at L707.

    while (readRegister(device,"%s.MONITOR.STATUS"%(scanBase)) > 0):

This seems to always evaluate to greater than 0. Observed both on the user account of cosmicstandtif and also as myself running the coffin setup.

Types of issue

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

Expected Behavior

Loop should not be infinite.

Current Behavior

Loop is infinite causing scan to not advance.

Steps to Reproduce (for bugs)

Configure Detector
Launch a threshold scan with ultraThreshold.py the --debug option

If the --debug option is not used it looks like the scan hangs.

See scan command executed and produced log files:

ultraThreshold.py -s2 -g0 --shelf=1 --nevts=1000 --vfatmask=0xf40400 --vt2=0 --perchannel --filename=/data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-VI-L-CERN-0002/threshold/channel/2017.09.20.17.13/ThresholdScanData.root --debug 2>&1 | tee "threshScanWithDebug.txt"

threshScanWithDebug_coffinSetup.txt

python /home/GE11COSMICS/Software/DAQ/vfatqc-python-scripts/ultraThreshold.py -s2 -g0 --shelf=3 --nevts=1000 --vfatmask=0xf40400 --vt2=0 --perchannel --filename=/data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-VI-L-CERN-0001/threshold/channel/2017.09.20.16.31/ThresholdScanData.root --debug 2>&1 | tee "threshScanWithDebug_Trial2_QC8.txt"

threshScanWithDebug_Trial2_QC8.txt

Your Environment

Version used (coffin setup): ab771dd
Version used (qc8): ab771dd
Shell used (coffin setup): /bin/zsh
Shell used (qc8): /bin/bash

Wrong python version used while compiling on SLC6

Brief summary of issue

after commit e3ebf87
the compiler picks the system python in all cases, while it should take locally installed python2.7 for SLC6.X OS

Types of issue

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

Expected Behavior

On SLC6 should pick up non-system wide python of version 2.7.X

Current Behavior

Compiler invokes system python which is of 2.6.6 version

Possible Solution (for bugs)

We can add one more env variable responsible for the version of OS, or make the XDAQ_OS var to be more than just linux as it is now

Your Environment

Version used: generic-amc-release-v3
Shell used: bash

Incorrect update of scan parameters

There is a bug in how the scan parameters are updated. Currently the parameter will update for each connected device, i.e., if there are two AMCs and four OHs connected all will start out with scanMin.
Then at the first transition, the first AMC will update to scanMin + stepSize and will update currentParameter to this value. The second AMC will then update to currentParameter + stepSize, and will update currentParameter to this value.
Likewise fore each connected OH.

Updates for uhal 2.5

In the 2.5 update to the uhal library, under the hood changes make "write-only" bitmasked registers invalid.
Need to update address tables where previously this was used to be "rw" rather than "w"

Handle printing of exceptions better in python scripts

Some exceptions result in a failure to print causing the python tool to crash. This behaviour needs to be fixed

An exception occurred cannot concatenate 'str' and 'exception' objects

Add output s-bit configuration to OH manager

Need to be able to configure the output s-bit mode and source from the manager
Propose adding a new config struct replacing sbitSource as per:

            <SBitConfig xsi:type="soapenc:Struct">
              <Mode xsi:type="xsd:integer">0</Mode>
              <Output0Src xsi:type="xsd:integer">0</Output0Src>
              <Output1Src xsi:type="xsd:integer">1</Output1Src>
              <Output2Src xsi:type="xsd:integer">2</Output2Src>
              <Output3Src xsi:type="xsd:integer">3</Output3Src>
              <Output4Src xsi:type="xsd:integer">4</Output4Src>
              <Output5Src xsi:type="xsd:integer">5</Output5Src>
            </SBitConfig>

Application crash on failed DB connection

Currently the software crashes when it tries (and fails) to connect to the database.
This should not happen, rather it should raise an exception to be handled, and put the application into ERROR

django.db.utils.OperationalError: (2003, "Can't connect to MySQL server on 'gem904daq01' (113)")
21 Sep 2016 11:37:54.449 [140229354694400] ERROR GEMDatabaseUtilsLogger <> - Error connecting to database 'ldqm_test_db' : Can't connect to MySQL server on 'gem904daq01.cern.ch' (113)
21 Sep 2016 11:37:54.449 [140229354694400] ERROR ch.cern.cosmicstandtif.p:5050.gem::supervisor::GEMSupervisor.instance(0) <> - GEMSupervisor::updateRunNumber unable to connect to the database (xcept)Error connecting to database 'ldqm_test_db' : Can't connect to MySQL server on 'gem904daq01.cern.ch' (113)
21 Sep 2016 11:37:54.449 [140229354694400] FATAL root <> - Unexpected exception in main thread
terminate called after throwing an instance of 'gem::utils::exception::Exception'
  what():  GEMSupervisor::updateRunNumber unable to connect to the database (xcept)Error connecting to database 'ldqm_test_db' : Can't connect to MySQL server on 'gem904daq01.cern.ch' (113)
Process [29251] on node cosmicstandtif.cern.ch terminates abnormally at 2016-09-21T06:37:54.450102-05:00. Caught signal 6 at address [0x43b100007243]
Stacktrace follows:
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox10stacktraceEiRSo+0x44) [0x7f89e7e51ce4]
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox18signalSEGVCallbackEiP7siginfoPv+0x262) [0x7f89e7e52972]
/lib64/libpthread.so.0() [0x3e1b00f7e0]
/lib64/libc.so.6(gsignal+0x35) [0x3e1a8325e5]
/lib64/libc.so.6(abort+0x175) [0x3e1a833dc5]
/usr/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x12d) [0x3e214bea7d]
/opt/xdaq/lib/libtoolbox.so(+0x4e98f) [0x7f89e7e5398f]
/usr/lib64/libstdc++.so.6() [0x3e214bcc16]
/usr/lib64/libstdc++.so.6(__cxa_call_unexpected+0x43) [0x3e214bc2a3]
//home/sturdy/gemdev/cmsgemos/gemsupervisor/lib/linux/x86_64_slc6/libgemsupervisor.so(_ZN3gem10supervisor13GEMSupervisor11startActionEv+0x79c) [0x7f89d13fb47c]
//home/sturdy/gemdev/cmsgemos/gembase/lib/linux/x86_64_slc6/libgembase.so(_ZN3gem4base17GEMFSMApplication5startEPN7toolbox4task8WorkLoopE+0x168) [0x7f89d170b358]
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox4task15WaitingWorkLoop7processEv+0x79) [0x7f89e7e8ceb9]
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox4task8WorkLoop3runEv+0x12a) [0x7f89e7e8944a]
/opt/xdaq/lib/libtoolbox.so(_ZN7toolbox4task11thread_funcEPv+0x97) [0x7f89e7e89887]
/lib64/libpthread.so.0() [0x3e1b007aa1]
/lib64/libc.so.6(clone+0x6d) [0x3e1a8e8aad]

Composite state handling

Brief summary of issue

The GEMSupervisor has its own FSM (as it is a GEMFSMApplicationbut it needs to calculate its own state from the composite state of the supervised applications. This is mostly implemented in theGEMGlobalState` class, but in certain instances the composite state is not correct.
Additionally, we need to ensure that the state change handling is done in a robust way, such that we don't prematurely report a final state when we should still report a transitional state.

Types of issue

Bug report (report an issue with the code)

Expected Behavior

The GEMSupervisor FSM state will reflect the composite state of the children at all times
An inhibition of the GEMSupervisor FSM state should be ensured at the initial transition

Scan routine integration at TIF

Testing of scan routines at TIF

Using LEMO scintillator triggers
S-curve testing
Multiple chambers simultaneously (can work into another issue for a later release if necessary)

gempython logging

Brief summary of issue

I have two loggers in the python code which queries the HW and updates the DB. A local logger for my amcmanager is blocking and disabling the logger from query.py. Do you know how this can be resolved?

Different update intervals for different hardware settings

Need to have different timers (or none at all) for different hardware monitoring updates

IPBus error logging needs improvement

IPBus error logging doesn't really help in the problem identification since the information printed to the log looks like:
[7f3063635700] ERROR - Returned Header from URI "ipbustcp-2.0://192.168.1.42:60002", 0x2B040104 ( transaction id = 0x00000B04, transaction type = 0x00, word count = 1 ) had response field = 0x04 indicating an error (1 bytes into IPbus reply payload)^[[0m
^[[0;31m28-06-17 16:42:32.563323
[7f3063635700] ERROR - Original sent header was 0x2B04010F, for base address 0x0040D020, 1 bytes into IPbus send payload
We need to add the info about which register was attempted to read in human-readable manner.
For example above I can guess that for base address 0x0040D020 means GEM_AMC.OH.OH0.ScanController.ULTRA.MONITOR, but it's not that straightforward.

Exception in amc_info_uhal.py if --short option not used at cmd line

When calling:

amc_info_uhal.py -s2 -g0 --shelf=3 --short 2>&1 | tee amc_info.txt

Expected behavior is obtained (see amc_info.txt)

When calling:

amc_info_uhal.py -s2 -g0 --shelf=3 2>&1 | tee amc_info_withException.txt

e.g. missing the --short argument an exception is thrown as shown in amc_info_withException.txt

HW configuration for local DB update

Brief summary of issue

Certain parameters like shelf number aren't passed to gem::utils::db::GEMDatabaseUtils::configure

Types of issue

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

Context (for feature requests)

Currently certain parameters as shelf used as default values. We can simply pass the needed parameters only, or eventually we can pass the full HW description from XDAQ XML config so that db query is created only for the configuration listed in that XML and we don't even try to update inactive/inexisting hardware

Issue on compile

When following instructions given:

https://twiki.cern.ch/twiki/bin/view/CMS/GEMOnlineSoftwareDevelopment#Setting_up_the_gemdaq_online_sof

When executing:

make clean && make all -j6

Returns the following error to terminal.

g++  -g -O2 -Wall -fPIC -fno-omit-frame-pointer -DGIT_VERSION=\"v0.1.0-920-gff7a6\" -DGEMDEVELOPER=\"dorney\" -std=c++0x -std=gnu++0x -I/usr/include/mysql  -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fwrapv -fPIC   -DUNIV_LINUX -DUNIV_LINUX -I/usr/include/mysql  -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fwrapv -fPIC   -DUNIV_LINUX -DUNIV_LINUX -DOS_VERSION_CODE=132640 -Dx86_64_slc6 -Dlinux -DLITTLE_ENDIAN__ -I/opt/xdaq/config -I/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/linux -I/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include -I/opt/xdaq/include -I/usr/local/include/python2.7 -I/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include -I/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/x86_64_slc6/include -I/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/x86_64_slc6/include/linux -I/opt/xdaq/include -I/opt/xdaq/include/linux -c -o /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/linux/x86_64_slc6/db/GEMDatabaseUtils.o /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/db/GEMDatabaseUtils.cc
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc: In member function ‘void gem::utils::gemXMLparser::parseGEMSystem(xercesc_3_1::DOMNode_)’:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:123:45: error: cannot bind ‘gem::utils::gemCrateProperties_ {aka gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties > >_}’ lvalue to ‘gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties > >_&&’
           p_gemSystem->addSubDeviceRef(crate);
                                             ^
In file included from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemXMLparser.h:28:0,
                 from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:6:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemComplexDeviceProperties.h:26:12: error:   initializing argument 1 of ‘void gem::utils::gemComplexDeviceProperties<T>::addSubDeviceRef(T_&&) [with T = gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties > >]’
       void addSubDeviceRef(T_ &&subDeviceRef) {m_subDevicesRefs.push_back(subDeviceRef);}
            ^
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc: In member function ‘void gem::utils::gemXMLparser::parseCrate(xercesc_3_1::DOMNode_)’:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:156:72: error: cannot bind ‘gem::utils::gemGLIBProperties_ {aka gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties >_}’ lvalue to ‘gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties >_&&’
           p_gemSystem->getSubDevicesRefs().back()->addSubDeviceRef(glib);
                                                                        ^
In file included from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemXMLparser.h:28:0,
                 from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:6:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemComplexDeviceProperties.h:26:12: error:   initializing argument 1 of ‘void gem::utils::gemComplexDeviceProperties<T>::addSubDeviceRef(T_&&) [with T = gem::utils::gemComplexDevicePropertiesgem::utils::gemComplexDeviceProperties<gem::utils::gemDeviceProperties >]’
       void addSubDeviceRef(T_ &&subDeviceRef) {m_subDevicesRefs.push_back(subDeviceRef);}
            ^
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc: In member function ‘void gem::utils::gemXMLparser::parseGLIB(xercesc_3_1::DOMNode_)’:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:187:98: error: cannot bind ‘gem::utils::gemOHProperties_ {aka gem::utils::gemComplexDevicePropertiesgem::utils::gemDeviceProperties_}’ lvalue to ‘gem::utils::gemComplexDevicePropertiesgem::utils::gemDeviceProperties_&&’
           p_gemSystem->getSubDevicesRefs().back()->getSubDevicesRefs().back()->addSubDeviceRef(oh);
                                                                                                  ^
In file included from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemXMLparser.h:28:0,
                 from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:6:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemComplexDeviceProperties.h:26:12: error:   initializing argument 1 of ‘void gem::utils::gemComplexDeviceProperties<T>::addSubDeviceRef(T_&&) [with T = gem::utils::gemComplexDevicePropertiesgem::utils::gemDeviceProperties]’
       void addSubDeviceRef(T_ &&subDeviceRef) {m_subDevicesRefs.push_back(subDeviceRef);}
            ^
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc: In member function ‘void gem::utils::gemXMLparser::parseOH(xercesc_3_1::DOMNode_)’:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:223:128: error: cannot bind ‘gem::utils::gemVFATProperties_ {aka gem::utils::gemDeviceProperties_}’ lvalue to ‘gem::utils::gemDeviceProperties_&&’
           p_gemSystem->getSubDevicesRefs().back()->getSubDevicesRefs().back()->getSubDevicesRefs().back()->addSubDeviceRef(vfat);
                                                                                                                                ^
In file included from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemXMLparser.h:28:0,
                 from /afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/common/gemXMLparser.cc:6:
/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/include/gem/utils/gemComplexDeviceProperties.h:26:12: error:   initializing argument 1 of ‘void gem::utils::gemComplexDeviceProperties<T>::addSubDeviceRef(T_&&) [with T = gem::utils::gemDeviceProperties]’
       void addSubDeviceRef(T_ &&subDeviceRef) {m_subDevicesRefs.push_back(subDeviceRef);}
            ^
make[2]: **\* [/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/src/linux/x86_64_slc6/gemXMLparser.o] Error 1
make[2]: **\* Waiting for unfinished jobs....
make[2]: Leaving directory `/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils'
make[1]: *** [/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils/.loop] Error 2
make[1]: Leaving directory`/afs/cern.ch/user/d/dorney/scratch0/CMS_GEM/cmsgemos/gemutils'
make: **\* [gemutils] Error 2

Bug in GEMSupervisor

It appears that there is a bug in the GEMSupervisor if the config file includes the GEMSupervisor application before some of the managed applications.
This may just need to be an operational paradigm, where the supervisor is listed after other applications and that's it.
However, all attempts to make the code more robust should be taken.
This may be a problem with the info space toolbox, or only in the supervisor.

[Thread 0x7fffcbfff700 (LWP 7595) exited]
25 Oct 2016 22:36:29.544 [140737316407360] WARN  ch.cern.gem904daq01.p:5050.gem::supervisor::GEMSupervisor.instance(0) <> - GEMMonitor::startMonitoring could not stop timer Cannot stop non active timer
[New Thread 0x7fffcbfff700 (LWP 7596)]
25 Oct 2016 22:36:29.546 [140737316407360] ERROR ch.cern.gem904daq01.p:5050.gem::supervisor::GEMSupervisor.instance(0) <> - Error trying to read from InfoSpace 'urn:xdaq-application:lid=30' state . Failed to get infospace, 'urn:xdaq-application:lid=30' not existing
Unexpected exception in toolbox::task thread
terminate called after throwing an instance of 'gem::base::utils::exception::InfoSpaceProblem'
  what():  Error trying to read from InfoSpace 'urn:xdaq-application:lid=30' state .

Program received signal SIGABRT, Aborted.
0x000000304d6325e5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install boost-system-1.41.0-28.el6.x86_64 cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 fontconfig-2.8.0-5.el6.x86_64 freetype-2.3.11-17.el6.x86_64 glibc-2.12-1.192.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libcurl-7.19.7-52.el6.x86_64 libgcc-4.4.7-17.el6.x86_64 libidn-1.18-2.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libssh2-1.4.2-2.el6_7.1.x86_64 libstdc++-4.4.7-17.el6.x86_64 libuuid-2.17.2-12.24.el6.x86_64 mysql-libs-5.1.73-7.el6.x86_64 ncurses-libs-5.7-4.20090207.el6.x86_64 nspr-4.11.0-1.el6.x86_64 nss-3.21.0-8.el6.cern.x86_64 nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 nss-util-3.21.0-2.el6.x86_64 numactl-2.0.9-2.el6.x86_64 openldap-2.4.40-12.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 pcre-7.8-7.el6.x86_64 readline-6.0-4.el6.x86_64 root-cint-5.34.36-1.el6.x86_64 root-core-5.34.36-1.el6.x86_64 root-graf-5.34.36-1.el6.x86_64 root-graf-gpad-5.34.36-1.el6.x86_64 root-graf-postscript-5.34.36-1.el6.x86_64 root-graf3d-5.34.36-1.el6.x86_64 root-hist-5.34.36-1.el6.x86_64 root-io-5.34.36-1.el6.x86_64 root-mathcore-5.34.36-1.el6.x86_64 root-matrix-5.34.36-1.el6.x86_64 root-net-5.34.36-1.el6.x86_64 root-physics-5.34.36-1.el6.x86_64 root-tree-5.34.36-1.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x000000304d6325e5 in raise () from /lib64/libc.so.6
#1  0x000000304d633dc5 in abort () from /lib64/libc.so.6
#2  0x00000030542bea7d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#3  0x00000030542bcc16 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x00000030542bc2a3 in __cxa_call_unexpected () from /usr/lib64/libstdc++.so.6
#5  0x00007fffe0c8e9d6 in gem::supervisor::GEMSupervisor::instantiate (stub=<value optimized out>) at /data/bigdisk/users/sturdy/software/cmsgemos/gemsupervisor/src/common/GEMSupervisor.cc:21
#6  0x00007ffff7dbdd88 in xdaq::ApplicationRegistry::instantiateApplication (this=0x7fffffffd188, descriptor=0x710530) at /usr/src/debug/daq-xdaq-4.9.1/src/common/ApplicationRegistry.cc:239
#7  0x00007ffff3170005 in executive::Application::instantiateApplications (this=0x6a4a00, partitionNode=<value optimized out>) at /usr/src/debug/daq-executive-4.0.6/src/common/Application.cc:1131
#8  0x00007ffff317e50b in executive::Application::Configure (this=0x6a4a00, partitionNode=0x6de3b8) at /usr/src/debug/daq-executive-4.0.6/src/common/Application.cc:253
#9  0x00007ffff317f55f in executive::Application::Configure (this=0x6a4a00, message=<value optimized out>) at /usr/src/debug/daq-executive-4.0.6/src/common/Application.cc:332
#10 0x00007ffff3189021 in xoap::Method<executive::Application>::invoke (this=0x6c4040, arg=<value optimized out>) at /opt/xdaq/include/xoap/Method.h:60
#11 0x00007ffff315ce95 in executive::SOAPDispatcher::processIncomingMessage (this=0x6a5910, msg=...) at /usr/src/debug/daq-executive-4.0.6/src/common/SOAPDispatcher.cc:346
#12 0x00007ffff2f2d689 in pt::http::SOAPLoopbackMessenger::send (this=<value optimized out>, message=<value optimized out>) at /usr/src/debug/daq-pthttp-4.5.4/src/common/SOAPLoopbackMessenger.cc:56
#13 0x00007ffff7dacf67 in xdaq::ApplicationContextImpl::postSOAP (this=0x7ffff2f2d5a0, message=..., originator=..., destination=<value optimized out>) at /usr/src/debug/daq-xdaq-4.9.1/src/common/ApplicationContextImpl.cc:1240
#14 0x00007ffff7db43d9 in xdaq::ApplicationContextImpl::init (this=0x7fffffffc600, argc=-13344, argv=0x6de0c8) at /usr/src/debug/daq-xdaq-4.9.1/src/common/ApplicationContextImpl.cc:695
#15 0x000000000040556d in main (argc=5, argv=0x7fffffffd638) at /usr/src/debug/daq-xdaq-4.9.1/src/common/xdaq.cc:162

Problem with ParameterQuery callback in GEMSupervisor

Brief summary of issue

The empty parameters box seems to be due to a failing callback to ParameterQuery.
This is also causing failures on the RCMS side, which executes a ParameterQuery as part of the attempt to get/send parameters

Types of issue

Bug report (report an issue with the code)

Expected Behavior

Parameter table will be properly populated
RCMS will send the parameters without error

Current Behavior

ParameterQuery returns SOAP fault string: <qns:message>Parameter export failed in ParameterQuery</qns:message>
The raw query will succeed before Initialize and crash after with message:

FATAL root <> - Unexpected exception in main thread
terminate called after throwing an instance of 'xdata::exception::Exception'
  what():  failed to create DOM element for item 'gem::hw::amc13::AMC13Manager:lid:255' with: attempt is made to create or change an object in a way which is incorrect with respect to namespaces
Process [30837] on node gem904daq01.cern.ch terminates abnormally at 2017-09-13T18:14:06.947413+02:00. Caught signal 6 at address [0x43b100007875]
Stacktrace follows:

This is from the way the applications are put into the Infospace for monitoring and needs to be reworked anyway

Steps to Reproduce (for bugs)

Start any GEMSupervisor config
Try to view the parameters in the hyperDAQ page
Note the empty field, if opening the JS console, a message will be seen

Bug Report: icomp value ignored

Noticed that the value passed to icomp in the CommonVFATSettings is not used and instead a value of 90 is applied to all chips.

Steps to repeat the problem:

->launch xdaq
->Initialize
->Configure
->Check VFAT Dashboard using the WebDAQ

You'll see icomp is 90.

Clean up logging implementation

Brief summary of issue

There are several places where the logging can be improved or streamlined, e.g., GEMSOAPToolBox

Create a wrapper class for the logging that has a few more functionalities than the simple macros we've already defined
Clean up unnecessary logging
Prioritize the messages properly

Types of issue

Maintenance

Add RCMS state reporting

Brief summary of issue

Need to add a few parameters to applications that will report their state to RCMS

Types of issue

Feature request (request for change which adds functionality)

Expected Behavior

If needed, applications will provide an infospace item that RCMS can query to obtain the application FSM state

Context (for feature requests)

RCMS requests ReportStateToRCMS to know whether the application will be sending asynchronous state transitions

Appropriate usage of const

Past #106, re-write to ensure that const correctness is appropriately applied in our code

Latency scan monitoring

Brief summary of issue

Latency scan doesn't provide any monitoring capabilities to see how the scan is progressing

Types of issue

Feature request: add certain monitoring printouts to the log file

Context (for feature requests)

I'm going to add following information:

OH CRC counters for each VFAT at the beginning of the scan and after it finishes- this might affect the number of triggers we take since the data with failed CRC may be discarded. QUESTION: do we want to add this printout (24 values per chamber) for all the scans or only for Latency?
Number of L1As reported by AMC13, CTP7 and OH (each 1000 L1As send from AMC13) -- only for Latency scan

Do I miss anything? Any other suggestions?

Invalid state requests

Brief summary of issue

Invalid state change requests should be considered:

We can receive a truly invalid request, i.e., Start from Initial
We can receive a request while in a transitional state, i.e., Start from Configuring

Expected Behavior

We can either ignore invalid requests or go to error, with an appropriate recovery mechanism, ignoring is probably better, because it is probably not the fault of the application that it received an invalid request
We can also ignore, but emit an error message, in this case the FSM stays in the state it was in, but the software is aware of something unexpected having happened
We can queue requests, this probably makes sense most for the transitions received during the transitional states, but still could have some implications, i.e., the state should be one in the "expected" flow of transitions: Initial -> Halted -> Configured -> Running, Paused with transitional states Initializing, Halting, Configuring, Starting, Pausing, Resuming, Stopping, Resetting

Broadcast transaction improvement

Make the broadcast transactions more robust by taking advantage of the OH firmware updates which return the status of the transaction, also checking the returned data for validity, and potentially retrying.

Feature Request: paths.sh checks status of uhal links

Brief summary of issue

When performing a SW update via git the uhal links in:

$BUILD_HOME/cmsgemos/setup/etc/addresstables

Are broken and a call of:

$BUILD_HOME/cmsgemos/setup/etc/addresstables/linkuhaltables.sh

Is required to restore the links.

Types of issue

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

Expected Behavior

Add a block of code in:

$BUILD_HOME/cmsgemos/setup/paths.sh

That would check if the links exist and are not broken. If they are found to be broken paths.sh should call linkuhaltables.sh

Something like: 

# Link connections & address tables
echo "Checking Links"
cd $BUILD_HOME/cmsgemos/setup/etc/addresstables
ln -sf connections_tif.xml connections.xml
if [ -L uhal_gem_amc_ctp7_amc.xml ]; then
    if readlink -q uhal_gem_amc_ctp7_amc.xml >/dev/null ; then
        echo "Links no good, re-making"
        ./linkuhaltables.sh $FIRMWARE_GEM/CTP7/address_table_v1_9_4 v1_9_4_GBT .
    else
        echo "Links Checkout"
    fi
fi

Don't know how to make indentations work, the above suggestion might need some tweaking.

Current Behavior

A call of:  $BUILD_HOME/cmsgemos/setup/etc/addresstables/linkuhaltables.sh
 Is required after every software update. This leads to the possibility that the person performing the update forgets to call the script as reported:  http://cmsonline.cern.ch/cms-elog/997946

Context (for feature requests)

 DAQ Expert making SW update forgets to call:  

$BUILD_HOME/cmsgemos/setup/etc/addresstables/linkuhaltables.sh
 Leads to downtime of the system.

@lmoureaux

Feature Request: Latency Scan Step Size From Command Line

Looking at:

[GE11COSMICS@cosmicstandtif 20170616]$ /home/GE11COSMICS/Software/DAQ/vfatqc-python-scripts/ultraLatency.py -h
Usage: ultraLatency.py [options]

Options:
-h, --help show this help message and exit
-s slot, --slot=slot slot in uTCA crate
-g gtx, --gtx=gtx GTX on the AMC
--shelf=shelf uTCA shelf to access
-d, --debug print extra debugging information
-r, --reset reset link error counters
--errors=errorRate calculate link error rates for N seconds
--testbeam fixed IP address for testbeam
--namc=namc Number of register tests to perform on the amc
(default is 100)
--noh=noh Number of register tests to perform on the OptoHybrid
(default is 100)
--ni2c=ni2c Number of I2C tests to perform on the VFAT2s (default
is 100)
--ntrk=ntrk Number of tracking data packets to readout (default is
1000)
--writeout Write the data to disk when testing the rate
--tests=tests Tests to run, default is all
--doLatency [OPTIONAL] Run latency scan to determine the latency
value
--QC3test [OPTIONAL] Run a shortened test after covers have been
applied
--ztrim=ztrim Specify the p value of the trim
--scanmin=scanmin Minimum value of scan parameter
--scanmax=scanmax Maximum value of scan parameter
--nevts=nevts Number of events to count at each scan point
--vt1=vt1 VThreshold1 DAC value for all VFATs
--vt2=vt2 Specify VT2 to use
--mspl=MSPL Specify MSPL. Must be in the range 1-8 (default is 4)
--filename=filename Specify Output Filename
--internal Run a latency scan using the internal calibration
pulse

There is no option to supply the step size of the latency scan from command line. Request feature implementation for an option like --stepSize which would go from --scanmin to --scanmax at the supplied step size.

VFAT Index Shifted By 1?

Brief summary of issue

Issue summarized here: http://cmsonline.cern.ch/cms-elog/996153
Problem appears on cosmicstandtif

Symptoms:
->Observed that anaUltraScurve.py only produced 1 of 3 expected output; additionally output data looks unusable
->Output from vfat_info_uhal.py reports data from VFATs that don't exist and reports no data from expected VFATs

Types of issue

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

Expected Behavior

->VFATs 0, 11 and 19 should report nonzero register values
->VFATs 10, 18 and 20-23 should report zero register values

Current Behavior

->VFATs 0, 11, and 19 report all zeros
->VFATs 10, 18, and 20 report data. This GEB has no 100 pin connector on VFAT10 and VFAT 18 has written "not working" on this GEB. Additionally I2C sector for VFATs 20-23 doesn't work.
->Symptoms consistent with VFAT idx in software being off by 1 as proposed by @cbravo135 . Seems to impact scan applications in vfatqc-python-scripts

Steps to Reproduce (for bugs)

See: http://cmsonline.cern.ch/cms-elog/996153

Turn LV on
Configure chamber using confChamber.py
Call vfat_info_uhal.py

Possible Solution (for bugs)

Suspect the problem is either related to vfat_user_functions.py/vfat_info_uhal.py, or it is a problem in the address tables.

Context (for feature requests)

Issue seems to prevent meaningful scans from being taken on the cosmic stand

Your Environment

Version used: generic-amc-release-v3-qc8
Shell used: bash

AMC13 manager configuration

AMC13 Manager crashes when attempting to connect to unavailable amc13 (e.g. wrong amc13 connection file provided)

Feature Request: EVT_SENT Register Reset on "Start":

If issuing "Start" the EVT_SENT register on the GLIBManager -> Card Page -> DAQ subtab the counter corresponding to this register does not reset while the L1AID register does. This could cause potential confusion.

Request that on "Start" this counter is reset along with the L1AID register. See image attached.

read/write register list using the multiple transactions per dispatch

Currently seeing an error of the following sort when sending multiple (some number, not all) uhal transactions per dispatch call.

16-06-17 17:06:29.992061 [7fadb4dfa700] ERROR - Wrong Protocol Version! 0 != 2
16-06-17 17:06:29.992116 [7fadb4dfa700] ERROR - Unable to parse reply header 0x00000000 from URI "ipbustcp-2.0://192.168.2.42:60002", 41 bytes into IPbus reply payload.
16-06-17 17:06:29.992133 [7fadb4dfa700] ERROR - Original sent header was 0x2498011F, for base address 0x0040A029, 121 bytes into IPbus send payload

Need to understand where the error is coming from (CTP7 or uhal)
Find if there is an undocumented behaviour of this functionality where only a specific number of transactions can be bundled, and this has to be done manually, rather than being taken care of by uhal/controlhub

Feature Request: Hex to Decimal Conversion in vfat_info_uhal.py

Brief summary of issue

For registers:

Latency
IPreampIn
IPreampFeed
IPreampOut
IShaper
IShaperFeed
IComp
VCal
VThreshold1
VThreshold2
CalPhase

Provide a command line flag --showDec such that these registers are printed in decimal format when calling vfat_info_uhal.py --shelf=X -sY -gZ.

This would also need said flag to be added to displayChipInfo() of vfat_user_functions.py. This could be set to false by default so that current behavior is not changed.

Types of issue

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

Expected Behavior

Registers listed above are displayed in decimal value instead of hex when the --showDec flag is provided.

Current Behavior

User has to convert from hex.

Context (for feature requests)

When trying to compare current settings with other files (e.g. vfatConfig.txt) it is cumbersome to constantly convert from hex to decimal.

Your Environment

Version used: ab771dd
Shell used: /bin/bash

XGI stream manipulation

Add tools to manipulate the xgi stream object to be able to add scripts/css to the HTML head tag rather than in the body tag for pages inheriting from the framework xgi::framework::bind and xgi::framework::deferredbind
Requires some careful though and ability to know when the stream buffer has been flushed, but if we can set it up properly, things will be nicer

Group HW updates into block transactions

Sending more requests per dispatch call will probably improve the overall performance of the software, passing off the message queuing to the control_hub.
Likely candidate for these are when updating for the web tables.
May require an update to the GEMHwDevice class, adding an std::map<std::string, uint32_t> signature to the writeRegs or readRegs functions (currently implemented as std::vector<std::string, uint32_t> and similar)

How to handle masked broadcast read transaction results

Brief summary of issue

If a user performs a broadcastRead using a mask, the result object contains only entries corresponding to the mask, in increasing order, followed by 0's filling out the 24 entries

Types of issue

Curiosity
Feature discussion (request comments for change in functionality)

Current Behavior

[sturdy@gem904daq01 gemdev/vfatqc-python-scripts]% vfat_info_uhal.py -s2 -g0
14 Sep 2017 10:14:34.643 [7f0495621700] INFO - optohybrid_user_functions_uhal::getOHObject <> - gem.shelf01.amc02.optohybrid00: Success!
14 Sep 2017 10:14:34.643 [7f0495621700] INFO - optohybrid_user_functions_uhal::getOHObject <> - gem.shelf01.amc02.optohybrid00: Success!

--=======================================--

Firmware:     Version        Date
AMC     :       1.9.4   23/5/2017
OH      :    2.2.d.fb  05/05/2017
# mask is0xff000000
GEB0 SlotID::     0      1      2      3      4      5      6      7      8      9     10     11     12     13     14     15     16     17     18     19     20     21     22     23
     ChipID::0xf69f 0xff24 0xfa28 0xff60 0xfa40 0xfa17 0xf75b 0xff2c 0xfeeb 0xf99b 0xffe7 0xff4c 0xf747 0xff87 0xff40 0xff6b 0xfa20 0xffcb 0xff48 0xfa2c 0xff9b 0xffdc 0xff83 0xf6bc
   ContReg0::  0x36   0x36   0x36   0x36   0x02   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36
   ContReg1::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg2::  0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30
   ContReg3::  0x04   0x01   0x01   0x03   0x03   0x02   0x03   0x02   0x00   0x01   0x00   0x01   0x00   0x00   0x01   0x03   0x01   0x02   0x00   0x01   0x00   0x00   0x00   0x00
    Latency::  0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0x00   0xa9   0xa9   0xa9   0xa9   0xa9
  IPreampIn::  0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90
IPreampFeed::  0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45
 IPreampOut::  0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81
    IShaper::  0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82
IShaperFeed::  0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57
      IComp::  0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65
       VCal::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
VThreshold1::  0x68   0x33   0x46   0x52   0x6e   0x71   0x77   0x8b   0x26   0x2a   0x00   0x36   0x3a   0x3c   0x4a   0x6f   0x38   0x36   0x00   0x3c   0x00   0x00   0x00   0x00
VThreshold2::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   CalPhase::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
None
# mask is0xff111111
GEB0 SlotID::     0      1      2      3      4      5      6      7      8      9     10     11     12     13     14     15     16     17     18     19     20     21     22     23
     ChipID::0xff24 0xfa28 0xff60 0xfa17 0xf75b 0xff2c 0xf99b 0xffe7 0xff4c 0xff87 0xff40 0xff6b 0xffcb 0xff48 0xfa2c 0xffdc 0xff83 0xf6bc 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
   ContReg0::  0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg1::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg2::  0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg3::  0x01   0x01   0x03   0x02   0x03   0x02   0x01   0x00   0x01   0x00   0x01   0x03   0x02   0x00   0x01   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
    Latency::  0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0x00   0xa9   0xa9   0xa9   0xa9   0x00   0x00   0x00   0x00   0x00   0x00
  IPreampIn::  0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x00   0x00   0x00   0x00   0x00   0x00
IPreampFeed::  0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x00   0x00   0x00   0x00   0x00   0x00
 IPreampOut::  0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x00   0x00   0x00   0x00   0x00   0x00
    IShaper::  0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x00   0x00   0x00   0x00   0x00   0x00
IShaperFeed::  0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x00   0x00   0x00   0x00   0x00   0x00
      IComp::  0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x00   0x00   0x00   0x00   0x00   0x00
       VCal::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
VThreshold1::  0x33   0x46   0x52   0x71   0x77   0x8b   0x2a   0x00   0x36   0x3c   0x4a   0x6f   0x36   0x00   0x3c   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
VThreshold2::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   CalPhase::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
None
# mask is0xff555555
GEB0 SlotID::     0      1      2      3      4      5      6      7      8      9     10     11     12     13     14     15     16     17     18     19     20     21     22     23
     ChipID::0xff24 0xff60 0xfa17 0xff2c 0xf99b 0xff4c 0xff87 0xff6b 0xffcb 0xfa2c 0xffdc 0xf6bc 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
   ContReg0::  0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x36   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg1::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg2::  0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x30   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   ContReg3::  0x01   0x03   0x02   0x02   0x01   0x01   0x00   0x03   0x02   0x01   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
    Latency::  0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0xa9   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
  IPreampIn::  0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x90   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
IPreampFeed::  0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x45   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
 IPreampOut::  0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x81   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
    IShaper::  0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x82   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
IShaperFeed::  0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x57   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
      IComp::  0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x65   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
       VCal::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
VThreshold1::  0x33   0x52   0x71   0x8b   0x2a   0x36   0x3c   0x6f   0x36   0x3c   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
VThreshold2::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00
   CalPhase::  0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00   0x00

Possible Solution

Require the user who passes in the mask to know that they must parse the output to match the mask
Return a variable sized array, but still requires the user to parse the mask and array
Return always a fixed size array (already done), with 0's for masked entries in the correct places (not done, 0's are always at the end)
Disable the mask, since the non-masked read does the "right" thing automatically
- What functionality will this break?

AMC configuration

why OH manager sets the IE mask, while it is a property of AMC card?
why we have bunch of constants defined in the GEMFSMApplication.h wihle they are subjected to change? I mean MAX_AMCS_PER_CRATE, MAX_OPTOHYBRIDS_PER_AMC and MAX_VFATS_PER_GEB
Actually, the MAX_OPTOHYBRIDS_PER_AMC is set to 9 and this contradicts with what's written in gemsupervisor xml config, which makes impossible the proper configuration of the AMC IE mask

Bug Report: GLIB FIFO Full @ Start

We performed an ultra-scan with the webDAQ to look at the thresholds before starting a run with xdaq.

We noticed that this fills the GLIB FIFO.

When starting the run with xdaq the FIFO was full and then no further triggers were accepted.

This seems like a rare case but maybe the GLIB FIFO should be "flushed" when pressing "start."

xdaq data taking for the cosmicstand fails

Brief summary of issue

@jsturdy and
@bdorney

running an xdaq on the cosmic stand we ran into different problems. The elog is is

http://cmsonline.cern.ch/cms-elog/998313

with three different logfiles, one for every time the scan was launched. They are

/home/GE11COSMICS/Software/DAQ/cmsgemos/xdaq_log_RunType_20170719.txt
/home/GE11COSMICS/Software/DAQ/cmsgemos/xdaq_log_RunType_20170719-2nd.txt
/home/GE11COSMICS/Software/DAQ/cmsgemos/xdaq_log_RunType_20170719-3th.txt

The log files contain the warnings and error messages received as well as the commands used to launch.

Types of issue

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

Exception in amc_info_uhal.py if -r option used at cmd line

Based on feedback from DAQ expert tried to issue a reset command to the CTP7 with command line option -r.

Generated the exception shown: amc_info_resetExcept.txt

Operational mode when using CCB standalone mezzanine

In order to use the CCB standalone mezzanine board several (TIF operation) things on the AMC13 must always be configured:

The AMC13 local TTC must be enabled
The AMC13 local local trigger mode must be enabled
- It does not need to be generating/sending triggers

Currently, during the scans and possibly in other situations as well, the AMC13Manager is taking the AMC13 out of local trigger mode and this causes massive problems (the "trigger" rate goes to 225MHz)

This issue should be resolved quickly, and I suspect that it will be a relatively straightforward fix

Force error on failed SOAP transitions

Currently SOAP commands sent to TCDS applications which can't reach their endpoint result in an application crash.
This needs to be changed to an error transition

TTS_OVERRIDE register is set to 0x8 by GLIBManager

Brief summary of issue

TTS_OVERRIDE should be 0. It was required to override it before, but not anymore. We need to fix it in XDAQ configuration

Types of issue

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

Local DB update problem

Python logging interface has been updated, however this update didn't propagate to all (sub)packages. Also it's logger usage is different in different python scripts.

Also wrong python version is used during compilation (system-wide python 2.6 instead of python 2.7)

Types of issue

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

Expected Behavior

Correct DB update

Current Behavior

Query module intended to update the local DB is not working correctly with the logger.
Due to wrong version of python involved in compilation of gemutils, django module is not available.
Minor: the import paths should be updated in the files related to query.py I have a patch for this.

Possible Solution (for bugs)

There're different ways to implement the new logging interface. One is:
`import gempython.utils.gemlogger as GEMLogger

gemlogger = GEMLogger.getGEMLogger(name)`

Considering the wrong python version, we can eventually alter a Makefile under gemutils

Also I propose to migrate all the DB-related python code under gempython/utils
Currently it is spread between utils and tools.

For the logging issue and migration I have a patch. However we still have to sort out compilation-related issue which invokes wrong version of python.

Your Environment

Version used: generic-amc-release-v3
Shell used: bash

Go to error when output file can not be created or written

Realized that there doesn't seem to be any upwards notification from the readout application to the supervisor (or even into the FSM of the readout application) if the desired output file can't be written.
This should cause the readout application's FSM to go to error

Feature Request: Hex 2 Decimal Conversion on Selected Registers

Would it be possible to change on GLIBManager -> Card Page -> DAQ the following registers:

->EVT_SENT
->L1AID
->RUN_PARAMS

To appear in decimal notation rather than Hex?

cms-gem-daq-project / cmsgemos Goto Github PK

cmsgemos's Introduction

cmsgemos

Code Status

Quick setup

General info

Contributing

cmsgemos's People

Contributors

Stargazers

Watchers

Forkers

cmsgemos's Issues

Brief summary of issue

Types of issue

Expected Behavior

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Your Environment

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Possible Solution (for bugs)

Your Environment

Brief summary of issue

Types of issue

Expected Behavior

Testing of scan routines at TIF

Brief summary of issue

Brief summary of issue

Types of issue

Context (for feature requests)

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Brief summary of issue

Types of issue

Brief summary of issue

Types of issue

Expected Behavior

Context (for feature requests)

Brief summary of issue

Types of issue

Context (for feature requests)

Brief summary of issue

Expected Behavior

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Context (for feature requests)

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Possible Solution (for bugs)

Context (for feature requests)

Your Environment

Brief summary of issue

Types of issue

Expected Behavior

Current Behavior

Context (for feature requests)

Your Environment

Brief summary of issue

Types of issue

Current Behavior

Possible Solution

Brief summary of issue

Types of issue

Brief summary of issue

Types of issue

Python logging interface has been updated, however this update didn't propagate to all (sub)packages. Also it's logger usage is different in different python scripts.