Event Builder: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
== Introduction to Event building in MIDAS == | == Introduction to Event building in MIDAS == | ||
MIDAS supports event building through a dedicated [[mevb]] | MIDAS supports event building through a dedicated <span style=" font-style:bold; font-size: 110%;">[[mevb]]</span> | ||
application. Similar to the [[Frontend Operation#Frontend|Frontend]], the <span style="color:darkcyan;">''mevb''</span> application | application. Similar to the [[Frontend Operation#Frontend|Frontend]], the <span style="color:darkcyan;">''mevb''</span> application | ||
requires the definition of an equipment structure which describes its mode of operation. | requires the definition of an equipment structure which describes its mode of operation. | ||
Line 12: | Line 12: | ||
* Data format (should match the source data format). | * Data format (should match the source data format). | ||
Based on the given buffer name provided at the start-up time through the " | Based on the given buffer name provided at the start-up time through the " ''-b <buffer_name>'' " argument supplied, the [[mevb]] utility will scan all the equipments and handle the building of an event based on the identical buffer name found in the equipment list if the frontend equipment type includes the "[[Equipment List Parameters#EQ_EB|EQ_EB]]" flag. | ||
<div id="EventFragment"></div> | <div id="EventFragment"></div> | ||
== | == Event Builder and related frontend fragment == | ||
It is possible that in the case of multiple [[Frontend Operation#Frontend|Frontends]], the same "fragment" code may run in the different hardware frontends. In order to prevent having to build nFragment different [[Frontend Application |Frontend tasks]], the | It is possible that in the case of multiple [[Frontend Operation#Frontend|Frontends]], the same "fragment" code may run in the different hardware frontends. In order to prevent having to build nFragment different [[Frontend Application |Frontend tasks]], the [[Frontend Application |Frontend task]] | ||
argument ''-i <index>'' will replicate the same application image with the necessary dynamic modification required for the proper Event Building operation. | |||
The index can be passed to the frontend application either by this argument, or by environment variable [[Environment Variables | The index can be passed to the frontend application either by this argument, or by environment variable [[Environment Variables#MIDAS_FRONTEND_INDEX|MIDAS_FRONTEND_INDEX]] | ||
The | The ''-i <index>'' argument will provide the index to be appended to the minimal set of | ||
parameters to distinguish the different frontends. These parameters are: | parameters to distinguish the different frontends. These parameters are: | ||
; frontend_name : Name of the frontend application. | |||
; equipment name : Name of the equipment (from the Equipment structure). | |||
; event buffer: Name of the destination buffer (from the Equipment structure). | |||
Asynchronized and synchronized data collection can be envisaged (see [[Mevb]]). | |||
- For '''asynchronized''' fragment collection, the composition of the "equipment name" in the Equipment definition requires the index format to be present (see [[#1.Asynchronized|example 1]]). | |||
- For '''synchronized''' gathering of the fragments, the composition of the "equipment name" and "event buffer" both require the index format to be present (see [[#2.Synchronized|example 2]]). | |||
Frontend | |||
Event buffer remains the same for all the fragments: | |||
== Examples of Frontend Code for fragment collection in the event builder == | |||
/* The frontend name (client name) as seen by other MIDAS clients | === 1.Asynchronized === | ||
... | Event buffer remains the same for all the fragments: | ||
char *frontend_name = "ebfe"; /* The frontend name (client name) as seen by other MIDAS clients */ | |||
... | |||
EQUIPMENT equipment[] = { | EQUIPMENT equipment[] = { | ||
{"Trigger<span style="color:red">%02d</span>", /* equipment name */ | |||
{"Trigger%02d", /* equipment name */ | |||
1, TRIGGER_ALL, /* event ID, trigger mask */ | 1, TRIGGER_ALL, /* event ID, trigger mask */ | ||
"BUFFER", /* event buffer */ | "BUFFER", /* event buffer */ | ||
Line 45: | Line 48: | ||
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */ | LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */ | ||
"MIDAS", /* format */ | "MIDAS", /* format */ | ||
=== 2.Synchronized === | |||
/* The frontend name (client name) as seen by other MIDAS clients | |||
char *frontend_name = "ebfe"; /* The frontend name (client name) as seen by other MIDAS clients */ | |||
... | ... | ||
EQUIPMENT equipment[] = { | EQUIPMENT equipment[] = { | ||
{"Trigger<span style="color:red">%02d</span>", /* equipment name */ | |||
{"Trigger%02d", /* equipment name */ | |||
1, TRIGGER_ALL, /* event ID, trigger mask */ | 1, TRIGGER_ALL, /* event ID, trigger mask */ | ||
"BUF%02d", /* event buffer */ | "BUF<span style="color:red">%02d</span>", /* event buffer */ | ||
EQ_POLLED | EQ_EB, /* equipment type + EQ_EB flag <<<<<< */ | EQ_POLLED | EQ_EB, /* equipment type + EQ_EB flag <<<<<< */ | ||
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */ | LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */ | ||
"MIDAS", /* format */ | "MIDAS", /* format */ | ||
Once the frontend is started with e.g. ''' -i 1 ''', the MIDAS client name, equipment name and, in the case of the synchronized event builder, | |||
> ebfe -i 1 -D | buffer name will be modified by adding the index number (1 in this case). | ||
... | |||
odbedit | |||
[local:midas:S]/Equipment>ls | > ebfe -i 1 -D | ||
Trigger01 | ... | ||
[local:midas:S]Trigger01>ls -lr | odbedit | ||
Key name Type #Val Size Last Opn Mode Value | [local:midas:S]/Equipment>ls | ||
--------------------------------------------------------------------------- | Trigger01 | ||
Trigger01 DIR | [local:midas:S]Trigger01>ls -lr | ||
Key name Type #Val Size Last Opn Mode Value | |||
--------------------------------------------------------------------------- | |||
Trigger01 DIR | |||
Common DIR | Common DIR | ||
Event ID WORD 1 2 18h 0 RWD 1 | Event ID WORD 1 2 18h 0 RWD 1 | ||
Line 91: | Line 94: | ||
Frontend name STRING 1 32 18h 0 RWD ebfe01 | Frontend name STRING 1 32 18h 0 RWD ebfe01 | ||
Frontend file name STRING 1 256 18h 0 RWD .../eventbuilder/ebfe.c | Frontend file name STRING 1 256 18h 0 RWD .../eventbuilder/ebfe.c | ||
... | ... | ||
Independently of the event ID, each fragment frontend will send its data to the composed | Independently of the event ID, each fragment frontend will send its data to the composed |
Revision as of 16:50, 28 October 2013
Introduction to Event building in MIDAS
MIDAS supports event building through a dedicated mevb application. Similar to the Frontend, the mevb application requires the definition of an equipment structure which describes its mode of operation.
The set of parameters for this equipment is limited to:
- Equipment name (appears in the Equipment list).
- Equipment type (should be 0).
- Destination buffer name (SYSTEM if destination event goes to logger).
- Event ID and Trigger mask for the build event (destination event ID).
- Data format (should match the source data format).
Based on the given buffer name provided at the start-up time through the " -b <buffer_name> " argument supplied, the mevb utility will scan all the equipments and handle the building of an event based on the identical buffer name found in the equipment list if the frontend equipment type includes the "EQ_EB" flag.
It is possible that in the case of multiple Frontends, the same "fragment" code may run in the different hardware frontends. In order to prevent having to build nFragment different Frontend tasks, the Frontend task argument -i <index> will replicate the same application image with the necessary dynamic modification required for the proper Event Building operation.
The index can be passed to the frontend application either by this argument, or by environment variable MIDAS_FRONTEND_INDEX
The -i <index> argument will provide the index to be appended to the minimal set of parameters to distinguish the different frontends. These parameters are:
- frontend_name
- Name of the frontend application.
- equipment name
- Name of the equipment (from the Equipment structure).
- event buffer
- Name of the destination buffer (from the Equipment structure).
Asynchronized and synchronized data collection can be envisaged (see Mevb). - For asynchronized fragment collection, the composition of the "equipment name" in the Equipment definition requires the index format to be present (see example 1). - For synchronized gathering of the fragments, the composition of the "equipment name" and "event buffer" both require the index format to be present (see example 2).
Examples of Frontend Code for fragment collection in the event builder
1.Asynchronized
Event buffer remains the same for all the fragments:
char *frontend_name = "ebfe"; /* The frontend name (client name) as seen by other MIDAS clients */
...
EQUIPMENT equipment[] = {
{"Trigger%02d", /* equipment name */
1, TRIGGER_ALL, /* event ID, trigger mask */
"BUFFER", /* event buffer */
EQ_POLLED | EQ_EB, /* equipment type + EQ_EB flag <<<<<< */
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
2.Synchronized
char *frontend_name = "ebfe"; /* The frontend name (client name) as seen by other MIDAS clients */ ... EQUIPMENT equipment[] = { {"Trigger%02d", /* equipment name */ 1, TRIGGER_ALL, /* event ID, trigger mask */ "BUF%02d", /* event buffer */ EQ_POLLED | EQ_EB, /* equipment type + EQ_EB flag <<<<<< */ LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */ "MIDAS", /* format */
Once the frontend is started with e.g. -i 1 , the MIDAS client name, equipment name and, in the case of the synchronized event builder,
buffer name will be modified by adding the index number (1 in this case).
> ebfe -i 1 -D ... odbedit [local:midas:S]/Equipment>ls Trigger01 [local:midas:S]Trigger01>ls -lr Key name Type #Val Size Last Opn Mode Value --------------------------------------------------------------------------- Trigger01 DIR Common DIR Event ID WORD 1 2 18h 0 RWD 1 Trigger mask WORD 1 2 18h 0 RWD 65535 Buffer STRING 1 32 18h 0 RWD BUF01 Type INT 1 4 18h 0 RWD 66 Source INT 1 4 18h 0 RWD 16777215 Format STRING 1 8 18h 0 RWD MIDAS Enabled BOOL 1 4 18h 0 RWD y Read on INT 1 4 18h 0 RWD 257 Period INT 1 4 18h 0 RWD 500 Event limit DOUBLE 1 8 18h 0 RWD 0 Num subevents DWORD 1 4 18h 0 RWD 0 Log history INT 1 4 18h 0 RWD 0 Frontend host STRING 1 32 18h 0 RWD hostname Frontend name STRING 1 32 18h 0 RWD ebfe01 Frontend file name STRING 1 256 18h 0 RWD .../eventbuilder/ebfe.c ...
Independently of the event ID, each fragment frontend will send its data to the composed
event buffer (BUFxx). The event builder task will make up a list of all the equipment
belonging to the same event buffer name (BUFxx). If multiple equipments exists in the same
frontend, the equipment type (EQ_EB) and the event buffer name will distinguish them.
\anchor idx_event_builder_flowchart The Event Builder flowchart below shows a general picture of the event process cycle of the task. The Event Builder runs in polling mode over all the source buffers collected at the begin of run procedure. Once a fragment has been received from all enabled source ("../Settings/Fragment Required y"), an internal event serial number check is performed prior passing all the fragment to the user code. Content of each fragment can be done within the user code for further consistency check.
*
* \image html eventbuilder.jpg*