Equipment List Parameters: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
== TABLE showing Equipment List Parameters ==
== TABLE showing Equipment List Parameters ==


'''<div id="B">B</div>'''
 
<div id="B">B</div>
 
[[#Equipment Name]] [[#EventID]] [[#TriggerMask]]  [[#Equipment Type]]  [[#Test1]]  [[#Buffer]]
 
[[#Equipment Type]] [[#EQ_PERIODIC]] [[#EQ_POLLED]] [[#EQ_INTERRUPT]] [[#EQ_MULTITHREAD]] [[#EQ_SLOW]]  [[#EQ_MANUAL_TRIG]]  [[#EQ_FRAGMENTED]]  [[#EQ_EB]]
 
[[#MirroredInODB]]


'''Note''' These parameters are copied to the ODB <span style="color: purple;">''/Equipment/<equipment-name>/Common''</span> subdirectory when the frontend is initialized.
'''Note''' These parameters are copied to the ODB <span style="color: purple;">''/Equipment/<equipment-name>/Common''</span> subdirectory when the frontend is initialized.
Line 11: Line 18:
| colspan="1" rowspan="1" style="vertical-align: top; background-color: rgb(255, 255, 204); font-weight: bold;" | Explanation
| colspan="1" rowspan="1" style="vertical-align: top; background-color: rgb(255, 255, 204); font-weight: bold;" | Explanation


|-  '''<div id="Equipment Name"></div>'''
'''<div id="Equipment Name"></div>'''
|- 
| colspan="1" rowspan="1"  style="vertical-align: top; background-color: rgb(255, 255, 255); color: red"  |Equipment Name
| colspan="1" rowspan="1"  style="vertical-align: top; background-color: rgb(255, 255, 255); color: red"  |Equipment Name
| Each equipment has to be assigned a <b> unique name </b> (i.e. no two equipments in the  same experiment may have the same name). The name will be the reference name of the equipment generating the event. Examples of typical Equipment Names are "Trigger","Scaler","Epics".
| Each equipment has to be assigned a <b> unique name </b> (i.e. no two equipments in the  same experiment may have the same name). The name will be the reference name of the equipment generating the event. Examples of typical Equipment Names are "Trigger","Scaler","Epics".
Line 18: Line 26:
|  style="text-align: center; font-weight: bold; vertical-align: top; background-color:turquoise; color: rgb(255, 255, 255);  " colspan="2" rowspan="1"  | EQUIPMENT_INFO  Structure
|  style="text-align: center; font-weight: bold; vertical-align: top; background-color:turquoise; color: rgb(255, 255, 255);  " colspan="2" rowspan="1"  | EQUIPMENT_INFO  Structure


|- style="background-color: mintcream; "      '''<div id="EventID"></div>'''  
'''<div id="EventID"></div>'''  
|- style="background-color: mintcream; "   
| style="color: seagreen;"                |  EventID
| style="color: seagreen;"                |  EventID
| Each equipment has to be associated with a  '''unique eventID''' . The event ID will be part of the event header of that particular equipment.
| Each equipment has to be associated with a  '''unique eventID''' . The event ID will be part of the event header of that particular equipment.


|-  style="background-color: mintcream; "    '''<div id="TriggerMask"></div>'''
'''<div id="TriggerMask"></div>'''
|-  style="background-color: mintcream; "   
| style="color: seagreen;"                | Trigger Mask
| style="color: seagreen;"                | Trigger Mask
| Each equipment must be associated with a <b> unique Trigger mask </b> if  the @ref FE_tbl_EqType "Equipment type" is  @ref FE_tbl_EqInterrupt "EQ_INTERRUPT" or @ref  FE_tbl_EqMultithread "EQ_MULTITHREAD".  In this case, the trigger mask can be modified dynamically by the readout routine to define a <b> sub-event type </b> on an event-by-event basis. This can be used to mix "physics events" (from a physics trigger) and "calibration events" (from a clock for example) in one run and identify them later. Both parameters are declared as 16bit values. If the Trigger mask is used in a single bit-wise mode, 16 is the maximum number of different masks available.   
| Each equipment must be associated with a <b> unique Trigger Mask </b> if  the [[#Equipment Type|Equipment Type]] is  "[[#EQ_INTERRUPT|EQ_INTERRUPT]]" or "[[#EQ_MULTITHREAD|EQ_MULTITHREAD]]".  In this case, the Trigger Mask can be modified dynamically by the readout routine to define a '''sub-event type''' on an event-by-event basis. This can be used to mix "physics events" (from a physics trigger) and "calibration events" (from a clock for example) in one run and identify them later. Both parameters are declared as 16bit values. If the Trigger Mask is used in a single bit-wise mode, 16 is the maximum number of different masks available.   


'''<div id="Buffer"></div>'''  '''<div id="MirroredInODB"></div>'''
|-  style="background-color: mintcream; "
|-  style="background-color: mintcream; "
| style="color: seagreen;"    | Buffer
| style="color: seagreen;"    | Buffer
|  Specifies the name of the Buffer to which the event will be sent. After composition of an "Equipment", the Midas frontend mfe.c
|  Specifies the name of the Buffer to which the event will be sent. After composition of an "Equipment", the Midas [[Frontend Operation#Frontend|Frontend]] ''mfe.c''
takes over the sending of this event to the buffer (usually the '''"SYSTEM"''' buffer) on the back-end computer  where it may be sent to the logger and the analyser.
takes over the sending of this event to the buffer (usually the '''"SYSTEM"''' buffer) on the back-end computer  where it may be sent to the data logger [[mlogger] and the [[analyser]].
 
*  If this field is left empty, (i.e. set to ""), the readout function associated with that equipment will still be performed, but the  actual event won't be sent to the buffer. Instead, that particular equipment can be '''mirrored in the ODB''' if the "[[#RO_ODB|RO_ODB]]" flag is turned on (see @ref  FE_RO_ODB_example "example").  The ODB is updated with a new event approximately every second. Note that this feature is generally used only for testing or monitoring, as writing large amounts of data to the ODB takes time.
* By using a buffer other than the "SYSTEM" buffer,  [[Event Filtering]] can be implemented.
* If using an [[Event Builder]] [[Mevb]] ( i.e. a secondary stage on the back-end to collect and assemble events coming from different buffers in order to
compose a larger event) , a dedicated buffer can be specified.  In this case the "[[#EQ_EB|EQ_EB]]" flag must be turned on, and the events coming from the  [[Frontend Operation#Frontend|Frontend]] are called  '''fragments'''.


*  @anchor FE_tbl_mirrorODB If this field is left empty, (i.e. set to ""),
the readout function associated with that equipment will still be performed, but the
actual event won't
be sent to the buffer. Instead, that
particular equipment can be <b>mirrored in the ODB</b> if the @ref  FE_tbl_ReadOn "RO_ODB" flag is
turned on (see @ref  FE_RO_ODB_example "example").  The ODB is updated with a new event approximately
every second. Note that this feature is generally used only for testing or monitoring, as writing large amounts
of data to the ODB takes time.
<li>By using a buffer other than the "SYSTEM" buffer,  @ref F_Logger_Event_Filtering "event filtering" can be
implemented.
<li>If using an \ref FE_Event_Builder  "Event Builder" ( i.e. a secondary
stage
on the back-end to collect
and assemble events coming from different buffers in order to
compose a larger event) , a dedicated buffer can be specified.  In
this case the  @ref FE_tbl_EqEb "EQ_EB" flag must be turned on, and the events coming from
the frontend are called \b fragments.
</ul>




Line 60: Line 58:
|
|


 
<div id="Test1"></div>
|-  style="background-color: mintcream; "
|-  style="background-color: mintcream; "
| style="color: seagreen;"   |  
| style="color: seagreen;"   |
|
|




Line 88: Line 86:
|  style="vertical-align: top; font-weight: bold;" | Explanation
|  style="vertical-align: top; font-weight: bold;" | Explanation


'''<div id="EQ_PERIODIC"></div>'''
|-  
|-  
| EQ_PERIODIC  
| EQ_PERIODIC  
Line 93: Line 92:
| In this mode no hardware requirement is necessary to @ref FE_tab_event_trigger "trigger" the readout function.  Instead, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with this equipment is called periodically.The @ref  FE_tbl_Period "Period" field in the equipment declaration is used in this case to specify the time interval between calls to the readout function.  See @ref FE_other_event "example".
| In this mode no hardware requirement is necessary to @ref FE_tab_event_trigger "trigger" the readout function.  Instead, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with this equipment is called periodically.The @ref  FE_tbl_Period "Period" field in the equipment declaration is used in this case to specify the time interval between calls to the readout function.  See @ref FE_other_event "example".


'''<div id="EQ_POLLED"></div>'''
|-
|-
|EQ_POLLED
|EQ_POLLED
Line 100: Line 100:
data acquisition based on a hardware condition becoming TRUE, at which time the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called. See  @ref FE_poll_event "example".
data acquisition based on a hardware condition becoming TRUE, at which time the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called. See  @ref FE_poll_event "example".


'''<div id="EQ_INTERRUPT"></div>'''
|-
|-
| EQ_INTERRUPT
| EQ_INTERRUPT
Line 105: Line 106:
| This modeis similar to the @ref FE_tbl_EqPolled "EQ_POLLED" mode except a hardware interrupt is used to @ref FE_tab_event_trigger "trigger" the event instead of a polling loop.  Instead of passing a pointer to the polling routine, in EQ_INTERRUPT mode a pointer to the <b> interrupt configuration routine </b> is passed to the system.  Midas requires complete configuration and control of the interrupt source. This is provided by an interrupt configuration routine called @ref  FE_interrupt_event "interrupt_configure()" that must be provided in the frontend.c by the user. When a valid interrupt is received, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called.See  @ref FE_interrupt_event "example".
| This modeis similar to the @ref FE_tbl_EqPolled "EQ_POLLED" mode except a hardware interrupt is used to @ref FE_tab_event_trigger "trigger" the event instead of a polling loop.  Instead of passing a pointer to the polling routine, in EQ_INTERRUPT mode a pointer to the <b> interrupt configuration routine </b> is passed to the system.  Midas requires complete configuration and control of the interrupt source. This is provided by an interrupt configuration routine called @ref  FE_interrupt_event "interrupt_configure()" that must be provided in the frontend.c by the user. When a valid interrupt is received, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called.See  @ref FE_interrupt_event "example".


'''<div id="EQ_MULTITHREAD"></div>'''
|-
|-
| EQ_MULTITHREAD
| EQ_MULTITHREAD
Line 111: Line 113:




'''<div id="EQ_SLOW"></div>'''
|-
|-
| EQ_SLOW
| EQ_SLOW
Line 116: Line 119:
| This flag declaresthe equipment as a Slow Control Equipment. This will enable the call tothe <b>idle</b> function part of the class driver. This flag also causes event data to be sent automatically to the /equipment/variables tree in the ODB.
| This flag declaresthe equipment as a Slow Control Equipment. This will enable the call tothe <b>idle</b> function part of the class driver. This flag also causes event data to be sent automatically to the /equipment/variables tree in the ODB.


'''<div id="EQ_MANUAL_TRIG"></div>'''
|-
|-
| EQ_MANUAL_TRIG
| EQ_MANUAL_TRIG
Line 121: Line 126:
| This flag enables the equipment to be @ref FE_Manual_trig_mode "triggered" by a remote procedure call (RPC). If EQ_MANUAL_TRIGGER is selected, the web interface will provide an extra button to trigger the equipment. The event may also be triggered by a client via RPC. @ref FE_manual_trigger "See example."
| This flag enables the equipment to be @ref FE_Manual_trig_mode "triggered" by a remote procedure call (RPC). If EQ_MANUAL_TRIGGER is selected, the web interface will provide an extra button to trigger the equipment. The event may also be triggered by a client via RPC. @ref FE_manual_trigger "See example."


'''<div id="EQ_FRAGMENTED"></div>'''
|-
|-
| EQ_FRAGMENTED
| EQ_FRAGMENTED
Line 129: Line 136:
: This flag was added for small memory cpus (e.g VxWorks PPC) to send very large events (beyond the Midas configuration limit) back to the host computer. With modern cpus that have large memory (e.g. VMIC), instead of using this flag, the '''buffer sizes should be increased''' to accommodate a large event (see [[Event Buffer]]). </span>
: This flag was added for small memory cpus (e.g VxWorks PPC) to send very large events (beyond the Midas configuration limit) back to the host computer. With modern cpus that have large memory (e.g. VMIC), instead of using this flag, the '''buffer sizes should be increased''' to accommodate a large event (see [[Event Buffer]]). </span>


'''<div id="EQ_EB"></div>'''
|-
|-
| EQ_EB
| EQ_EB

Revision as of 17:13, 24 October 2013

TABLE showing Equipment List Parameters

B

#Equipment Name #EventID #TriggerMask #Equipment Type #Test1 #Buffer

#Equipment Type #EQ_PERIODIC #EQ_POLLED #EQ_INTERRUPT #EQ_MULTITHREAD #EQ_SLOW #EQ_MANUAL_TRIG #EQ_FRAGMENTED #EQ_EB

#MirroredInODB

Note These parameters are copied to the ODB /Equipment/<equipment-name>/Common subdirectory when the frontend is initialized.

EQUIPMENT Parameter Explanation
Equipment Name Each equipment has to be assigned a unique name (i.e. no two equipments in the same experiment may have the same name). The name will be the reference name of the equipment generating the event. Examples of typical Equipment Names are "Trigger","Scaler","Epics".
EQUIPMENT_INFO Structure
EventID Each equipment has to be associated with a unique eventID . The event ID will be part of the event header of that particular equipment.
Trigger Mask Each equipment must be associated with a unique Trigger Mask if the Equipment Type is "EQ_INTERRUPT" or "EQ_MULTITHREAD". In this case, the Trigger Mask can be modified dynamically by the readout routine to define a sub-event type on an event-by-event basis. This can be used to mix "physics events" (from a physics trigger) and "calibration events" (from a clock for example) in one run and identify them later. Both parameters are declared as 16bit values. If the Trigger Mask is used in a single bit-wise mode, 16 is the maximum number of different masks available.
Buffer Specifies the name of the Buffer to which the event will be sent. After composition of an "Equipment", the Midas Frontend mfe.c

takes over the sending of this event to the buffer (usually the "SYSTEM" buffer) on the back-end computer where it may be sent to the data logger [[mlogger] and the analyser.

  • If this field is left empty, (i.e. set to ""), the readout function associated with that equipment will still be performed, but the actual event won't be sent to the buffer. Instead, that particular equipment can be mirrored in the ODB if the "RO_ODB" flag is turned on (see @ref FE_RO_ODB_example "example"). The ODB is updated with a new event approximately every second. Note that this feature is generally used only for testing or monitoring, as writing large amounts of data to the ODB takes time.
  • By using a buffer other than the "SYSTEM" buffer, Event Filtering can be implemented.
  • If using an Event Builder Mevb ( i.e. a secondary stage on the back-end to collect and assemble events coming from different buffers in order to

compose a larger event) , a dedicated buffer can be specified. In this case the "EQ_EB" flag must be turned on, and the events coming from the Frontend are called fragments.







Equipment Type should be set to one of the Equipment Flags EQ_XXX selected from the following Table:

Equipment Types Explanation
EQ_PERIODIC Periodic Event In this mode no hardware requirement is necessary to @ref FE_tab_event_trigger "trigger" the readout function. Instead, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with this equipment is called periodically.The @ref FE_tbl_Period "Period" field in the equipment declaration is used in this case to specify the time interval between calls to the readout function. See @ref FE_other_event "example".
EQ_POLLED Polling Event In this mode, the name of the routine performing the @ref FE_tab_event_trigger "trigger" check function is @ref FE_poll_event "poll_event()". This routine must be provided in the frontend.c by the user. As polling consists of checking a variable for a TRUE condition, if the loop count is infinite and the condition never becomes TRUE, the frontend would not be able to respond to any network commands. Therefore the loop count is determined when the frontend starts for the first time so that it returns

after a given time-out if no event is available. This time-out is usually of the order of 500 milliseconds.
The EQ_POLLED equipment type is mainly used for data acquisition based on a hardware condition becoming TRUE, at which time the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called. See @ref FE_poll_event "example".

EQ_INTERRUPT Interrupt Event This modeis similar to the @ref FE_tbl_EqPolled "EQ_POLLED" mode except a hardware interrupt is used to @ref FE_tab_event_trigger "trigger" the event instead of a polling loop. Instead of passing a pointer to the polling routine, in EQ_INTERRUPT mode a pointer to the interrupt configuration routine is passed to the system. Midas requires complete configuration and control of the interrupt source. This is provided by an interrupt configuration routine called @ref FE_interrupt_event "interrupt_configure()" that must be provided in the frontend.c by the user. When a valid interrupt is received, the @ref FE_tbl_ReadoutRoutine "readout routine" associated with the equipment is called.See @ref FE_interrupt_event "example".
EQ_MULTITHREAD Multithread Event Readout Thisequipment type implements themulti-threading capability within the frontend code. The polling isperformed within a separate thread and uses the@ref rbfunctionc "Midas Ring Buffer Functions" (rb_xxx) for inter-thread communication.EQ_MULTITHREAD is similar to @ref FE_tbl_EqPolled "EQ_POLLED" mode, except for the polling function which in the case of EQ_MULTITHREAD resides in a separate thread. This new type has been added to take advantage of the multi-core processor to free up CPU for tasks other than polling.


EQ_SLOW Slow Control Event This flag declaresthe equipment as a Slow Control Equipment. This will enable the call tothe idle function part of the class driver. This flag also causes event data to be sent automatically to the /equipment/variables tree in the ODB.


EQ_MANUAL_TRIG Manual triggered event This flag enables the equipment to be @ref FE_Manual_trig_mode "triggered" by a remote procedure call (RPC). If EQ_MANUAL_TRIGGER is selected, the web interface will provide an extra button to trigger the equipment. The event may also be triggered by a client via RPC. @ref FE_manual_trigger "See example."


EQ_FRAGMENTED Fragmented Event Obsolescent flag EQ_FRAGMENTED enabled large events (beyond the Midas configuration limit) to be handled by the system (see note below). This flag required that a valid max_event_size_frag variable is defined in the user Frontend code. The max_event_size variable was used as fragment size in this case. This option was meant to be used in experiments where the event rate was not an issue but the size of the data needed to be extremely large. @ref FE_fragmented_event "See example."

NOTE:

This flag was added for small memory cpus (e.g VxWorks PPC) to send very large events (beyond the Midas configuration limit) back to the host computer. With modern cpus that have large memory (e.g. VMIC), instead of using this flag, the buffer sizes should be increased to accommodate a large event (see Event Buffer).


EQ_EB Event run through the event builder This flag identifies the equipment as a fragment event and should be ORed with the EQ_POLLED in order to be identified by the \ref FE_Event_Builder. Not to be confused with a fragmented event (see above)!