• AHCALTestBeamCERN2015
• EUDAQOperation

EUDAQ operation

Contents

This page is a branch of the main AHCALTestBeamCERN2015 page. More specifically, is a part of the Operation section.

The EUDAQ Pc is physically located at the testbeam area. We are connected to it locally by ethernet cable (hut --> switch --> EUDAQ Pc).

We are currently working with version EUDAQ1.4.5, in a CentOS7 machine. The manual for this version can be read here.

Never accept any update in the system.

Take care of not click in "Shutdow+Update" button.

In july we lost some runs (Muon runs at the begining) for some, yet unknown, reason related to automatic system updates.

It seems that some of the updates played around with the port permissions in a nasty way.

Before Running the eudaq

The eudaq pc is connected to the CERN network, so we can connect to it just doing ssh/rdesktop:

rdesktop -z -P -K -u calice 137.138.115.151

if rdesktop does not work, do :

ssh -X calice@137.138.115.151

EUDAQ path:

/home/calice/eudaq-1.4.5-TestBeamCern/calice_eudaq

Run numbering, folder names.

Data folder

/home/calice/eudaq-1.4.5-TestBeamCern/data/CERN_SPS_July2015/

and

/home/calice/eudaq-1.4.5-TestBeamCern/data/CERN_SPS_August2015/

Runnumber

The run number is defined in

/home/calice/eudaq-1.4.5-TestBeamCern/data/runnumber.dat

This file should contain the previous recorded runnumber. The EUDAQ automatically increases it by one when a new run starts.

This number cannot be changed while the EUDAQ is working (it won't care of the change)

Configuration files

Example of configuration file, see it in:

/home/calice/eudaq-1.4.5-TestBeamCern/conf/TB_july2015.conf

Normally, we only care about these 3 lines:

waitsecondsForQueuedEvents = 3

Which is the sleeping time after the comand stop, in order to wait for the queued events.

RawFileName = "CERN_SPS_August2015/rawdata/Run_%05d"

All the raw data is stored in the same folder, only for debugging purposes, for the moment.

FilePattern = "CERN_SPS_August2015/Muon/Run_$5R$X.slcio

WE MIGHT WANT TO CHANGE THIS for the different kind of runs (Pions, muons, etc...)

The current list of configuration files (for the August period) is shown here:

Pions
-------------------------------------------------
TB_August2015_Pion_120GeV.conf --> Pion 120 GeV

Muons
-------------------------------------------------
TB_August2015_Muon.conf        --> Muons, not caring of the energy of them
TB_August2015_Muon_120GeV.conf --> Muons, 120 GeV

Tests
-------------------------------------------------
testruns_TB_august2015.conf --> only for tests. It does not save any binary raw file. The slcio file is saved in a test folder.
                                Rememeber to check the runnumber after using this configuration since it is automatically increased...
                                do we want to restart the data taking from the previous good run number?

Before start the data taking, each of these configuration files should be ready for different kind of runs for different particle content of the beam and also different energy of such particles, as well as the correspondent folders to store the data.

Taking data with EUDAQ

0) Put the Labview in Listen Mode !! See final section of Labview_configuration_for_beam_data_taking for more details.

cd /home/calice/eudaq-1.4.5-TestBeamCern/calice_eudaq
./TESTBEAM_2015

1) choose the configuration file,

2) Clic Configure

3) If everything is green, click start.

4) Stop when you want.

5) After stop, wait ~3-5 s of grace. We should see the following message

OnCompleteEvent()

in the log-window. If not, wait few seconds more (~5s) and start normally. In the case that this message has not appeared, we will see one error/warning message in the next run, this is because the first event number is mismatch due to buffered information from the previous run. We might lost this first readout cycle, which is not a big deal.

6) Go to point 3 (NOT CONFIGURE IT AGAIN)

The Run Control looks like:

and the log as:

We might see some runs starting in the 257 readout cycle. The reason for that is not yet understood, but this is fixed automatically during the a posteriori event building.

EUDAQ crashes

The most usual reasons for a crash of the eudaq are:

• the folder where we are saving the data does not exist in the Labview PC.
• the folder where we are saving the data does not exist in the EUDAQ PC (then EUDAQ crashes and make crash the Labview).
• we did some change in the Labview settings without unclick the Listen button.

If this happens, probably the Labview will crash too (or it did before). Restart it.

For the eudaq, check that the run number is the correct and that the folders exist.

Then restart it and pick the appropiate configuration file.