Data Acquisition and Slow Control

name of document

daqslow.html

version

0.3

author

M. Münch

date

18-07-2000

draft

purpose

This document proposes a common understanding of the slow control operations needed for the data acquisition system. Please note that this propositions differ from current practice, so if it is agreed upon, changes to software will be necessary in all detector groups.

revision history

1. v0.1 by M.Münch, define steps during start and stop of DAQ
2. v0.2 by M.Münch, change definition of software interface
3. v0.2 by M.Münch, update for nov00 beam time

project status

continuing

Slow Control Operations

The slow control system must be able to perform the following operations. All the operations should be possible to perform on the whole HADES system (all electronics and DAQ software) as well as on the following sub systems: RICH, MDC, PreShower, TOF (including START), TRIG, DAQ (DAQ-Software). The status of the slow control software itself (including run control for the DAQ-Software) shall not be changed by any of the operations.

init

Initializes the corresponding system. This includes all operations that are necessary after a power cycle. Init shall also be possible on a running system for recovery after a major failure. The init includes the reset operation.

reset

Brings the system from any state (e.g. newly initialized, running, crashed...) to a state where a start is possible. A reset on a running system shall not destroy stored data, but may discard data from buffers. A reset does not include an init.

start

Brings the system from the reset status to a status where data can be acquired.

stop

Stops acquisition of data and allows data to be transferred from the buffers to the storage. It does not include a reset.

Normal Operations

Start

1. Reset all electronics
2. Start all electronics
3. Start all readout software
4. Start CTU (make begin run trigger, enable external trigger sources)

Stop

1. Stop CTU (inhibit external trigger sources
2. Stop all electronics (flushes data from buffers)
3. Stop all readout software

Notes:

• Each start of the whole system includes a reset of all electronics.
• The readout software will not perform any initialization/deinitialization tasks.
• The above described scheme differs from the scheme used up to now. Up to now, the init did not include the reset and the start and stop operations where done by the data acquisition software itself.

Software Support for Slow Control

For each board that shall be controlled by slow control, a C-Code file including the necessary functions for performing the above tasks must be provided. This implies also the corresponding header with function prototypes. This file will be used as library for several applications:

• For stand alone programs by adding a second file with main() and resulting in the well known *ctrl programs.
• In the EPICS Channel Access Server for central control with the EPICS system.
• As library that may be used by vxWorks.

All symbols that are visible in global name space must be prepended by the prefix Boardtype to prevent name clashes. The functions expect a board name, i.e. a name to find the parameters for that specific board, and a structure that allows to fetch operating parameters via an arbitrary mechanism. Up to now, this mechanism will be a simple text file containing the parameters ("param.tcl"). It will be substituted by a link to the Oracle database in the future. The functions return an integer reporting success (0) or error (-1).

Assume a board of type Blub. The header file named blub_lib.h would look like this:

#ifndef BLUB_LIB_H
#define BLUB_LIB_H

#include <param.h>

int Blub_init(const char *name, const Param *param);
int Blub_reset(const char *name, const Param *param);
int Blub_start(const char *name, const Param *param);
int Blub_stop(const char *name, const Param *param);

#endif

Stand alone Programs for Tests

For stand alone tests and as long as the DAQ slow control is not integrated into the EPICS system, a few simple place holders shall be provided.

Drivers for the library

Using the *_lib.[ch] files described above, for each board a simple driver ("main program") shall be provided. It shall be named boardtypectrl and recognize the slow control operations and the board name as parameter.

For example, one Blub board (named blub0) can be reset with the command:

$ blubctrl reset blub0

static char rcsId[] = "$Id: RunControlStatesNov00.txt,v 1.2 2005/06/02 12:37:05 SimonLang Exp www-data $";

#include <stdlib.h>
#include <stddef.h>
#include <stdio.h>
#include <strings.h>

#include "param.h"

#include "blub_lib.h"

void usage(char *commandName) {
fprintf(stderr, "Usage: %s command boardName\n", commandName);
fprintf(stderr, "where command may be one of the following:\n");
fprintf(stderr, "init\n");
fprintf(stderr, "reset\n");
fprintf(stderr, "start\n");
fprintf(stderr, "stop\n");
fprintf(stderr, "status\n");
}


int main(int argc, char *argv[]) {
Param paramS, *param = &paramS;
char *name;
char *command;

if(argc < 3) {
usage(argv[0]);
exit(EXIT_FAILURE);
}

command = argv[1];
name = argv[2];

if (-1 == conParam(param)) {
perror("conParam");
exit(EXIT_FAILURE);
}

if(strcmp(command, "init") == 0) {
Blub_init(name, param);
} else if(strcmp(command, "reset") == 0) {
Blub_reset(name, param);
} else if(strcmp(command, "start") == 0) {
Blub_start(name, param);
} else if(strcmp(command, "stop") == 0) {
Blub_stop(name, param);
} else if(strcmp(command, "status") == 0) {
Blub_status(name, param);
} else {
usage(argv[0]);
exit(EXIT_FAILURE);
}

desParam(param);
exit(EXIT_SUCCESS);
}

Obvious problems in that code are error handling and safe deinitialization, these are postponed until more experience with the EPICS CAS is available.

Note: This driver is a placeholder for the EPICS control. Don't try to add fancy functionality that may not be possible to reflect in EPICS.

Scripts for concrete configurations

The setup of a whole subsystem usually consists of the setup of several boards, therefore several calls to *ctrl programs. For this operation, a script shall be provided to init, reset, start and stop a whole subsystem. This script shall be called like the subsystem itself (rich, mdc, shw, tof). Called without any further parameters, it shall do the requested operation for the currently usable configuration.

For example, the setup of the whole rich subsystem (DTU, CTU, RC etc.) is done with

$ rich init

Note: The purpose of this script is to reflect the currently running configuration, so they need to be changed every time the configuration is changed. Please do not try to parameterize the scripts, the scripts shall provide the necessary knowledge, not the user.