bu_cms_history/The_Anatomy_of_Monitoring

SiteMap (Historical BU CMS wiki main page)

hcaDCCMonitoring

Table column names are set with standard strings, defined static and constant:

 static const std::string label_EvB("EvB");
 static const std::string label_SLinkBlockCounter("SLinkBlockCounter");	

Tables must be inherited to (?) the hcalDCCMonitoring class. They take as their only definition-time parameter the String by which they are labeled in the infospace, which is just the list of monitorables available to be added to flashlists. Adding an Update Listener to a working table allows the Collector to execute automatic calls to the update method (discussed below) when the table is included in a flashlist with automatic collection enabled. Logging messages resulting from these automatic calls are labeled "" in the log (as opposed to those induced by clicking 'Collect' by hand.)

 hcalDCCMonitoring::hcalDCCMonitoring() 
  : m_perLRB("ErrorLRB"), m_perDCC("DCCWorld") {
 ...
  m_perDCC.addUpdateListener(this);
 }

Table monitorables must be published explicitly in order to get into the DCCManager infospace (or any other infospace), which is just the list of monitorables available to be added to flashlists.

 std::vector hcalDCCMonitoring::getMonitorables() {
   std::vector stuff;
   stuff.push_back(&m_perLRB);  
   stuff.push_back(&m_perDCC);  
   return stuff;
 }

Every monitorable item's individual update method must be callable by hcalDCCMonitoring::update(hcal::monitor::Monitorable* item). This is the method called by the Collector, so it effectively forms an automatable wrapper for the individual tables' update functions.

For the time being in hcalDCCMonitoring, all tables are created by the same function. This may merit retooling.

  1. Their columns are added to them using static constant strings.
  2. Any constant, identifying values or initial values are set from xdata variables whose values may come from hardware reads. ''Do monitorable tables only contain xdata types?''
  3. The tables' update methods are called in which the hardware reads take place.

 void hcalDCCMonitoring::createTables() {
  ...
  m_perDCC.addColumn(label_FED,"int");  
  m_perDCC.addColumn(label_EvB, "int");
  m_perDCC.addColumn(label_SLinkBlockCounter, "int");
  ...

 for (j=m_DCCcards.begin(); j!=m_DCCcards.end(); ++j) {
    xdata::Integer xi_fed(j->first);
    xdata::Integer xi_slot(j->second->getSlot());
    // Here we initialize the table entries of m_perDCC
    xdata::Integer xi_EvB(0xFFFF);
    m_perDCC.setValueAt(irow,label_FED,xi_fed);
    m_perDCC.setValueAt(irow,label_EvB,xi_EvB);
    m_perDCC.setValueAt(irow,label_SLinkBlockCounter,xi_EvB);
  ...
  }
  updatePerLRB(); 
  updatePerDCC();
}

Finally, hardware-reading update functions must be specified.

Flashlist, , and the directory tree

The HyperDAQ (and later I think, HyperMonVis) will consult dist/etc and dist/etc/flash/ for the xml profile and the details of the flashlists referenced by the profile, in those directories respectively. These were created and filled at (I think) the execution of the HCAL DAQ install script from the contents of hcal/config/monitor and hcal/config/flash (so it is this latter pair of directories into which modifications must go for distribution).