Frontend Operation: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
No edit summary
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Introduction ==
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4">
* [[Midas_documentation|Midas Documentation]]
* [[Feature_listing|Feature Listing]]
* [[Application_listing|Application Listing]]
* [[Online_Database|Online Database]]
</div>


The terms that are needed for a discussion of a <span style="color: green; font-style:italic; ">''frontend''</span> will be introduced here. The features of a typical <span style="color: green; font-style:italic; ">''frontend task''</span> will then be explained by reference to some of the examples included with the MIDAS package.


= Links =
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[Frontend Application]]
* [[Frontend_user_code|Frontend Code]]
</div>


== Frontend  ==
 
 
 
= Introduction =
 
The terms that are needed for a discussion of a <span style="color: green; font-style:italic; ">''frontend''</span> will be introduced here. The features of a typical <span style="color: green; font-style:italic; ">''frontend task''</span> will be explained by reference to some of the templates included with the MIDAS package (see [[Frontend_user_code|Frontend Code]]).
 
= Frontend  =


The term "<span style="color: green; font-style:italic; ">''frontend''</span>" usually refers to a "<span style="color: green; font-style:italic; ">''frontend task''</span>" or program running on a particular computer which has access to hardware equipment in use by the experiment. An experiment may
The term "<span style="color: green; font-style:italic; ">''frontend''</span>" usually refers to a "<span style="color: green; font-style:italic; ">''frontend task''</span>" or program running on a particular computer which has access to hardware equipment in use by the experiment. An experiment may
run several <span style="color: green; font-style:italic; ">''frontends''</span>, each performing different functions.  
run several <span style="color: green; font-style:italic; ">''frontends''</span>, each performing different functions.  


A <span style="color: green; font-style:italic; ">''frontend task''</span> consists of   
A <span style="color: green; font-style:italic; ">''frontend application''</span> consists of   
* a fixed  experiment-independent system framework  (i.e. '''''mfe.c''''')
* a fixed  experiment-independent system framework  (i.e. '''''mfe.c''''')
: handling the data flow control, data transmission and run control operation.
: handling the data flow control, data transmission and run control operation.
Line 22: Line 38:
The term "<span style="color: green; font-style:italic; ">frontend code</span>"  in this document usually refers to the user part (i.e. ''frontend.c''), since the system framework (''mfe.c'') is fixed.  
The term "<span style="color: green; font-style:italic; ">frontend code</span>"  in this document usually refers to the user part (i.e. ''frontend.c''), since the system framework (''mfe.c'') is fixed.  


To build a <span style="color: green; font-style:italic; ">frontend task</span>, the user code ''frontend.c'' and system code ''mfe.c'' are compiled and linked together with the required libraries, by running a '''Makefile''' (e.g.  ''../midas/examples/experiment/Makefile'' in the MIDAS package).
To build a <span style="color: green; font-style:italic; ">frontend task</span>, the user code ''frontend.c'' and system code ''mfe.c'' are compiled and linked together with the required libraries, by running a ''Makefile'' (e.g.  ''../midas/examples/experiment/Makefile'' in the MIDAS package).
   
   
A "<span style="color: green; font-style:italic; ">''frontend task''</span>"
A "<span style="color: green; font-style:italic; ">''frontend task''</span>"
may have any name the user chooses (e.g. ''fevme, fegpib'').  
may have any name the user chooses (e.g. ''fevme, fegpib''). To run the task, see [[Frontend Application]].
 
= Hardware Access =
 
Examples of hardware modules that may be accessed by the [[#Frontend |Frontend]] are ADC modules, TDC modules, Scaler modules. See [[Supported Hardware]]; The frontend is usually linked to a '''device driver''' for the particular hardware in use. Device drivers (i.e. header and library file) for many common hardware modules ( VME, GPIB, RS232 and CAMAC) are provided in the MIDAS package (see [https://bitbucket.org/tmidas/midas/src/93fa5ed4a40df94d4241e4a1910e44d1c5c8b866/drivers/?at=develop Git Repository /Drivers]).
 
= Equipments and Events =
In MIDAS,  "''hardware equipment''" refers to a collection of hardware (or devices) that are grouped together for convenience of readout, such as
* a set of high voltage supplies
* one or more crates of digitizing electronics e.g. ADCs and TDCs
* a set of scalers
 
Under MIDAS, ''hardware equipment(s)'' from the experiment are structured into software entities also called "''Equipments''".  From a software point of view, we keep this same term, i.e. "''Equipment''", to refer to the means of collecting the data related to hardware equipment. Thus the term "'''''Equipment'''''" refers to  ''a
single or a collection of sub-tasks meant to collect and regroup logical or physical data under a single and uniquely identified event''.
 
An "'''''event'''''" is thus a collection of data sent into the data stream by an ''Equipment''.
 
= Equipments in Frontends =
 
A single [[#Frontend|frontend]] may contain several [[#Equipments and Events|equipments]]. For example, an experiment may have a frontend to service
crates of ADC, TDC and Scaler modules. The ADC and TDC modules may be grouped together in
one equipment, and the scalers in a second equipment.
 
In complex experimental setups, several frontends controlling different sets of hardware equipment may be attached
simultaneously to a given experiment, i.e. they share the same Online Database (ODB). For example, one frontend might
service some VME hardware (TDCs,ADCs,Scalers), while another might service some slow-controls hardware via GPIB.
 
 
= Frontend Features =
 
A typical frontend will:
 
*    Register the given equipment list(s) to a specific MIDAS experiment.
*    Provide the mean of collecting data from the hardware source defined by each Equipment read function.
*    Gather these data in one of the supported formats (i.e. FIXED format or in MIDAS data bank(s) ) for each Equipment.
*    Send these data banks to the buffer manager either locally or remotely.
*    Periodically collect statistics of the acquisition task, and send them to the Online Database.
 
 
== Data transfer from the frontend ==
The system frontend [[#Frontend |framework]] (''mfe.c'') sends events to the buffer manager and optionally a copy to the Online Database (ODB). A "Data cache" in the frontend and on the server side reduces the amount of network operations pushing the transfer speed closer to the physical  limit of the network configuration.


A frontend's data transfer can be '''optimized''' for all kinds of experiments. Those where  multiple small events are produced can have the data built into  "[[Super Event]]s", by removing the bank headers to reduce the amount of data transferred.


== Frontend Task ==
An  [[Event_Builder |"event builder"]] mechanism is also available,
The purpose of a <span style="color: green; font-style:italic; ">''frontend task''</span> is to collect data from the hardware and transmit this information to a central place where data logging and
that can combine events from many different frontends into a composite event.
analysis can be performed.  


A  <span style="color: green; font-style:italic; ">''frontend task''</span> is built by the user
== Frontend event triggers ==
(see [[#Frontend]]) and consists of as "user part" and a "system framework" 


== Arguments ==
The data collection in the frontend framework can be triggered by several mechanisms.
The framework code (mfe.c) has the following arguments:
Currently the frontend supports five different kind of event trigger (see [[Equipment Flags]]).


  [-h hostname ] : host name (see @ref RC_odbedit_utility)
; Periodic events :
  [-e exptname ] : experiment name (see @ref RC_odbedit_utility)
Scheduled event based on a fixed time interval. They can be used to read information such as scaler values, temperatures etc.
  [-D ] : Become a Daemon.
; Polled events :  
  [-O ] : Become a Daemon but keep stdout
Hardware signal read continuously for a certain time period. If the signal is TRUE, the Equipment readout will be triggered.
  [-d ] : Used for debugging the frontend
; Interrupt events :  
  [-i index] : Set frontend index (used with @ref FE_mevb_utility . See also @ref  FE_principle_eb).
Generated by particular hardware device supporting interrupt mode  (e.g. LAM if CAMAC).
; Slow Control events :
Special class of events that are used in the slow control system.
; Manual events :
Triggered by a remote procedure call (RPC). The web interface provides an extra
button for manual triggering by the user.


Note that the new argument (-i index) has been introduced to
Each of these types of trigger can be enabled or activated for a particular experiment's  [[Run States and Transitions |run or transition state]] or a combination of any of them.
facilitate the multiple frontend configuration operation required for the [[Event Builder]]


== Usage ==
Examples such as
* read scaler event only when running : or
* read periodic event if the run state is  not paused  and on all transitions
are possible.


A frontend can also cause a transition to be  '''delayed ''' until a particular condition is met (see  [[Run States and Transitions#Deferred Transitions |Deferred Transitions]]).


Start the application as a daemon, using the default host, experiment and port :
==Event Readout Functions==
Associated with each Equipment is an readout function which runs when an Equipment is triggered. This function performs the actions required at the Equipment trigger, for example reading out the Equipment data and packing it into banks.


e.g. fevme -D


Start the application superceding the default host, experiment and port:
Examples of these features and more are shown in [[Frontend_user_code|Frontend Code]].


e.g. fegpib -e exp218 -h isdaq10 -p 7077 -D
[[Category:Frontend]]

Latest revision as of 16:21, 6 July 2015


Links



Introduction

The terms that are needed for a discussion of a frontend will be introduced here. The features of a typical frontend task will be explained by reference to some of the templates included with the MIDAS package (see Frontend Code).

Frontend

The term "frontend" usually refers to a "frontend task" or program running on a particular computer which has access to hardware equipment in use by the experiment. An experiment may run several frontends, each performing different functions.

A frontend application consists of

  • a fixed experiment-independent system framework (i.e. mfe.c)
handling the data flow control, data transmission and run control operation.
  • a user part (e.g. frontend.c)
written by the user describing the sequence of actions to acquire the hardware data

A set of templates for the user part is provided in the MIDAS package (e.g. ../midas/examples/experiment/frontend.c).

The hardware access is only apparent in the user part ( referred to here as frontend.c, but the user may select any name). The system framework is contained in the file mfe.c, which is part of the MIDAS package (the name "mfe" stands for "MIDAS front end").

The term "frontend code" in this document usually refers to the user part (i.e. frontend.c), since the system framework (mfe.c) is fixed.

To build a frontend task, the user code frontend.c and system code mfe.c are compiled and linked together with the required libraries, by running a Makefile (e.g. ../midas/examples/experiment/Makefile in the MIDAS package).

A "frontend task" may have any name the user chooses (e.g. fevme, fegpib). To run the task, see Frontend Application.

Hardware Access

Examples of hardware modules that may be accessed by the Frontend are ADC modules, TDC modules, Scaler modules. See Supported Hardware; The frontend is usually linked to a device driver for the particular hardware in use. Device drivers (i.e. header and library file) for many common hardware modules ( VME, GPIB, RS232 and CAMAC) are provided in the MIDAS package (see Git Repository /Drivers).

Equipments and Events

In MIDAS, "hardware equipment" refers to a collection of hardware (or devices) that are grouped together for convenience of readout, such as

  • a set of high voltage supplies
  • one or more crates of digitizing electronics e.g. ADCs and TDCs
  • a set of scalers

Under MIDAS, hardware equipment(s) from the experiment are structured into software entities also called "Equipments". From a software point of view, we keep this same term, i.e. "Equipment", to refer to the means of collecting the data related to hardware equipment. Thus the term "Equipment" refers to a single or a collection of sub-tasks meant to collect and regroup logical or physical data under a single and uniquely identified event.

An "event" is thus a collection of data sent into the data stream by an Equipment.

Equipments in Frontends

A single frontend may contain several equipments. For example, an experiment may have a frontend to service crates of ADC, TDC and Scaler modules. The ADC and TDC modules may be grouped together in one equipment, and the scalers in a second equipment.

In complex experimental setups, several frontends controlling different sets of hardware equipment may be attached simultaneously to a given experiment, i.e. they share the same Online Database (ODB). For example, one frontend might service some VME hardware (TDCs,ADCs,Scalers), while another might service some slow-controls hardware via GPIB.


Frontend Features

A typical frontend will:

  • Register the given equipment list(s) to a specific MIDAS experiment.
  • Provide the mean of collecting data from the hardware source defined by each Equipment read function.
  • Gather these data in one of the supported formats (i.e. FIXED format or in MIDAS data bank(s) ) for each Equipment.
  • Send these data banks to the buffer manager either locally or remotely.
  • Periodically collect statistics of the acquisition task, and send them to the Online Database.


Data transfer from the frontend

The system frontend framework (mfe.c) sends events to the buffer manager and optionally a copy to the Online Database (ODB). A "Data cache" in the frontend and on the server side reduces the amount of network operations pushing the transfer speed closer to the physical limit of the network configuration.

A frontend's data transfer can be optimized for all kinds of experiments. Those where multiple small events are produced can have the data built into "Super Events", by removing the bank headers to reduce the amount of data transferred.

An "event builder" mechanism is also available, that can combine events from many different frontends into a composite event.

Frontend event triggers

The data collection in the frontend framework can be triggered by several mechanisms. Currently the frontend supports five different kind of event trigger (see Equipment Flags).

Periodic events

Scheduled event based on a fixed time interval. They can be used to read information such as scaler values, temperatures etc.

Polled events

Hardware signal read continuously for a certain time period. If the signal is TRUE, the Equipment readout will be triggered.

Interrupt events

Generated by particular hardware device supporting interrupt mode (e.g. LAM if CAMAC).

Slow Control events

Special class of events that are used in the slow control system.

Manual events

Triggered by a remote procedure call (RPC). The web interface provides an extra button for manual triggering by the user.

Each of these types of trigger can be enabled or activated for a particular experiment's run or transition state or a combination of any of them.

Examples such as

  • read scaler event only when running : or
  • read periodic event if the run state is not paused and on all transitions

are possible.

A frontend can also cause a transition to be delayed until a particular condition is met (see Deferred Transitions).

Event Readout Functions

Associated with each Equipment is an readout function which runs when an Equipment is triggered. This function performs the actions required at the Equipment trigger, for example reading out the Equipment data and packing it into banks.


Examples of these features and more are shown in Frontend Code.