Skip to content

DAQModules

Marco Roda edited this page Jun 19, 2020 · 11 revisions

This page should contain the documentation for DAQModule interface.

DAQModule UML

The DAQModule is the main insertion point for user-written code. Each DAQModule should be self-contained and focused on a single task. "Self-contained" means that it should not rely on the presence of any other DAQModules in the same application. The "Single task" can be as complex as necessary to achieve the desired functionality.

The DAQModule interface has the role of associating each command to an operation. The association is configurable but eventually each command has to be associated to a single member function that

  • returns a void
  • accepts as an input a const vector<string> & from which to extract command specifics.

The association is done via the method register_command that every module calls during initialisation phase so that proper command response could be associated to each command name.

Whenever a DAQModule is created by the DAQProcess, the DAQProcess initiates a first configuration operation via do_init() and calls the init() method before any execute_command can be invoked.

GraphConstructor

The GraphConstructor is the object that essentially decouples the configuration interfaces with the construction of the DAQProcess. In this context is relevant as it is the objects that defines the order followed by the DAQProcess to distribute the commands to the DAQModules.

Ownership and instantiation

Each DAQModule is instantiated by the DAQProcess and they are owd by it for all the lifetime of the application. The appframework does not limit the DAQModules that can be instantiated as it is expected that every package depending on the framework will add their own modules.

Clone this wiki locally