1 / 7

Short summary of the main points discussed during the 1st day of the meeting on JMDC tests and DAQ procedures of sep 1

cael
Download Presentation

Short summary of the main points discussed during the 1st day of the meeting on JMDC tests and DAQ procedures of sep 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    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 tasks inside JMDC a set of tasks can be defined

    5. JMDC and tasks main difference with Andrei’s 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 don’t 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

More Related