70 likes | 257 Vues
E N D
1. Short summary of the main points discussed during the 1st day of the meeting on JMDC tests and DAQ procedures of sep 1st 2009 (the title is longer than the summary!)
M.Incagli - INFN Pisa
2. Starting from the end Scheme proposed by Andrei: DAQ is continuos, runs are defined as intervals of ~1/2hour (time defined by tracker)
Key points:
perform on JMDC all checks of calibration, configuration, house keeping
react by restarting the run (=DAQ config+calib)
3. Two main questions are config data and calib data part of the run?
these blocks are identified by block type and can be easily written in a separate area; they can be connected to a run, or set of runs, via time stamp or run number stamp
Is one of the JMDC duties to unpack data (=config, calib, HK) and analyze the content?
4. A proposal: JMDC and tasksinside JMDC a set of tasks can be defined
5. JMDC and tasks main difference with Andreis proposal: check of HK (and maybe also of config) is asynchronous (=not inside RUN task in new language)
however logical structure is the same: HK data, calib nd config are unpacked, checked on line and automatic decisions are taken
6. Other points discussed yesterday sending commands to detectors: no common library of commands foreseen;
each subdetector is responsible of the format used to send a command to a node: the command to set HV on an ECAL channel maybe different from a command to set HV on a RICH channel -> I (=M.I.) still dont feel confortable with this
7. the default set of parameters of each node is written in a configuration file loaded on DSP
a permanent modification of a parameter (eg HV value of a channel) needs a new configuration file loaded through 1553
configuration files do not exceed ~200B, so they are not considered as large (this statement should be checked)
loading a code (new DSP code, new tracker code,) is much more painful and should be done only if strictly necessary