Frontend Operation

Links

• Frontend Application

Introduction

The terms that are needed for a discussion of a frontend will be introduced here. The features of a typical frontend task will then be explained by reference to some of the examples included with the MIDAS package.

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 task 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 Modules

Examples of hardware modules that may be accessed by the Frontend are ADC modules, TDC modules, Scaler modules. See Current supported Hardware;

Hardware Drivers

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

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.

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.

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

Multiple Equipments and 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. 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 (see @ref FE_tbl_ReadOn "RO_Flags" ).

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.