Introduction - Top - Quick Start 
Midas system is based on a modular scheme that allows scalability and flexibility. Each component's operation is handled by a sub-set of functions. but all the components are grouped in a single library (libmidas.a, libmidas.so(UNIX), midas.dll(NT)).
The overall C-code is about 80'000 lines long and makes up over 450 functions (version 1.9.0). But from a user point of view, only a subset of these routines are needed for most operations.
Each Midas component is briefly described below but throughout the documentation more detailed information will be given regarding each of their capabilities. All these components are available from the "off-the-shelf" package. Basic components such as the Buffer Manager, Online Database, Message System, Run Control are by default operationals. The other needs are to be enabled by the user simply by either starting an application or by activation of the component through the Online Database. A general picture of the Midas system is displayed below.
The main elements of the Midas package are listed below with a short description of its functionality.
A buffer is organized as a FIFO (First-In-First-Out) memory. Consumers can specify which type of events they want to receive from a buffer. For this purpose each event contains a MIDAS header with an event ID and other pertinent information.
Buffers can be accessed locally or remotely via the MIDAS server. The data throughput for a local configuration composed of one producer and two consumers is about 10MB/sec on a 200 MHz Pentium PC running Windows NT. In the case of remote access, the network may be the essential speed limitation element.
A common problem in DAQ systems is the possible crash of a client, like a user analyzer. This can cause the whole system to hang up and may require a restart of the DAQ inducing a lost of time and eventually precious data. In order to address this problem, a special watchdog scheme has been implemented. Each client attached to the buffer manager signals its presence periodically by storing a time stamp in the shared memory. Every other client connected to the same buffer manager can then check if the other parties are still alive. If not, proper action is taken consisting of removing the dead client hooks from the system leaving the system in a working condition.
The main advantage of this concept is that all programs participating in an experiment have full access to these data without having to contact different computers. The possible disadvantage could be the extra load put on the particular host serving the ODB.
The ODB is located completely in shared memory of the back-end computer. The access function to an element of the ODB has been optimized for speed. Measurement shows that up to 50,000 accesses per second local connection and around 500 accesses per second remotely over the MIDAS server can be obtained.
The ODB is hierarchically structured, similar to a file system, with directories and sub-directories. The data is stored in pairs of a key/data, similar to the Windows NT registry. Keys can be dynamically created and deleted. The data associated with a key can be of several types such as: byte, words, double words, float, strings, etc. or arrays of any of those. A key can also be a directory or a symbolic link (like on Unix).
The Midas library provides a complete set of functions to manage and operate on these keys. Furthermore any ODB client can register a Hot Link between a local C-structure and a element of the ODB. Whenever a client (program) changes a value in this sub-tree, the C-structure automatically receives an update of the changed data. Additionally, a client can register a callback function which will be executed as soon as the hot-link's update has been received. For more information see ODB Structure.
This program is composed of a general framework which is experiment independent, and a set of template routines for the user to fill. This program will:
The frontend framework takes care of sending events to the buffer manager and optionally a copy to the 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.
The data collection in the frontend framework can be triggered by several mechanisms. Currently the frontend supports four different kind of event trigger:
Each of these types of triggering can be enabled/activated for a particular experiment state, Transition State or a combination of any of them. Examples such as "read scaler event only when running" or "read periodic event if a state is not paused and on all transitions" are possible.
Dedicated header and library files for hardware access to CAMAC, VME, Fastbus, GPIB and RS232 are part of Midas distribution set. For more information see Frontend code.
Basic functionality of the logger includes:
The analyzer is structured into "stages", where each stage analyzes a subset of the event data. Low level stages can perform ADC and TDC calibration,while high level stages can calculate "physics" results. The same analyzer executable can be used to run online (receive events from the buffer manager) and off-line (read events from file). When running online, generated N-tuples/TTree are stored in a ring-buffer in shared memory. They can by analyzed with PAW without stopping the run. For ROOT please refer to the documentation ...
When running off-line, the analyzer can read MIDAS binary files, analyze the events, add calculated data for each event and produce a HBOOK RZ output file which can be read in by PAW later. The analyzer framework also supports analyzer parameters. It automatically maps C-structures used in the analyzer to ODB records via Hot Link. To control the analyzer, only the values in the ODB have to be changed which get automatically propagated to the analyzer parameters. If analysis software has been already developed, Midas provides the functionality necessary to interface the analyzer code to the Midas data channel. Support for languages such as C, FORTRAN, PASCAL is available.
Three "Run State" define the state of Midas Stopped, Paused, Running. In order to change from one state to another, Midas provides four basic "Transition" function Tr_Start, Tr_pause, Tr_resume, Tr_Stop. During these transition periods, any Midas client register to receive notification of such message will be able to perform its task within the overall run control of the experiment.
In Order to provide more flexibility to the transition sequence of all the midas clients connected to a given experiment, each transition function has a transition sequence number attached to it. This transition sequence is used to establish within a given transition the order of the invocation of the Midas clients (from the lower seq.# to the largest).
To control a device it is then enough to modify the demand values in the database. The modified value gets automatically propagated to the slow control system, which in turn uses specific device driver to control the particular hardware. Measured values from the hardware are periodically send back to the ODB to reflect the current status of the sub-system.
The Slow control system is organized in "Classes Driver ". Each Class driver refers to a particular set of functionality of that class i.e. High-Voltage, Temperature, General I/O, Magnet etc. The implementation of the device specific is done in a second stage "Device Driver" while the actual hardware implementation is done in a third layer "Bus Driver". The current MIDAS distribution already has some device driver for general I/O and commercial High Voltage power supply system (see Supported hardware). The necessary code composing the hardware device driver is kept simple by only requiring a "set channel value" and "read channel value". For the High Voltage class driver, a graphical user interface under Windows or Qt is already available. It can set, load and print high voltages for any devices of that class.
The activation of a recording is not controlled by the history function but by the actual equipment (see Frontend code). This permits a higher flexibility of the history system such as dynamic modification of the event structure without restarting the Midas logger. At any given time, data-over-time relation can be queried from the disk file through a Midas utility mhist task or displayed through the mhttpd task.
The history data extraction from the disk file is done using low level file function giving similar result as a standard database mechanism but with faster access time. For instance, a query of a value, which was written once every minute over a period of one week, is performed in a few seconds. For more information see History system, ODB /History Tree.
The action triggered by the alarm is left to the user through the mean of running a detached script. But basic aalrm report is available such as:
Introduction - Top - Quick Start