Frontend Operation: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
No edit summary
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==== Links ====
<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>
 
 
= Links =
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[Frontend Application]]  
* [[Frontend Application]]  
*  
* [[Frontend_user_code|Frontend Code]]
*
</div>
</div>


== 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 then be explained by reference to some of the examples included with the MIDAS package.




== 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 34: Line 43:
may have any name the user chooses (e.g. ''fevme, fegpib''). To run the task, see [[Frontend Application]].
may have any name the user chooses (e.g. ''fevme, fegpib''). To run the task, see [[Frontend Application]].


== Hardware Modules ==
= Hardware Access =
 
Examples of hardware modules that may be accessed by the [[#Frontend |Frontend]] are ADC modules, TDC modules, Scaler modules. See [[Current supported Hardware]];
 
== Hardware Drivers ==
The [[#Frontend|Frontend]] is usually linked to a  "device driver" for the particular hardware in use.
A device driver (or "driver") is a piece of code that allows the computer to access some particular hardware.


Dedicated header and library files (i.e. drivers) for 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]).
to VME, GPIB, RS232 and CAMAC are part of the MIDAS distribution set.
Several libraries and drivers exist for the various bus systems. See [[MIDAS Driver Library]].


== Equipments and Events ==
= 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  
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  
* a set of high voltage supplies  
Line 52: Line 53:
* a set of scalers
* 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.  
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
 
=== Definitions ===
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''.  
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''.
An "'''''event'''''" is thus a collection of data sent into the data stream by an ''Equipment''.


== Multiple Equipments and Frontends ==
= Equipments in Frontends =


A single frontend may contain several ''Equipments''. For example, an experiment may have a [[#frontend|frontend]] to service  
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  
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''.
one equipment, and the scalers in a second equipment.


In complex experimental setups, several frontends controlling different sets of hardware equipment may be attached  
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. For example, one frontend might  
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.
service some VME hardware (TDCs,ADCs,Scalers), while another might service some slow-controls hardware via GPIB.




== Frontend Features ==
= Frontend Features =


A typical frontend will:
A typical frontend will:


*   Register the given Equipment list(s) to a specific MIDAS experiment.
*   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.
*    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.
*    Gather these data in one of the supported formats (i.e. FIXED format or in MIDAS data bank(s) ) for each Equipment.
Line 83: Line 81:


== Data transfer from the frontend ==
== 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  
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.
reduces the amount of network operations pushing the transfer speed closer to the physical  
limit of the network configuration.


=== Optimizing ===
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.  
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.  


An  [[Event_Builder |"event builder"]] mechanism is also available,  
An  [[Event_Builder |"event builder"]] mechanism is also available,  
Line 96: Line 91:


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


; Periodic events :
; Periodic events :
Line 110: Line 105:
button for manual triggering by the user.
button for manual triggering by the user.


 
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.  
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.  


Examples such as  
Examples such as  
* read scaler event only when running : or
* read scaler event only when running : or
* read periodic event if the run state is  not paused  and on all transitions
* 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]]).
==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.


are possible (see @ref FE_tbl_ReadOn "RO_Flags" ).
Examples of these features and more are shown in [[Frontend_user_code|Frontend Code]].


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

Latest revision as of 17: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.