The EUDAQ Pc is physically located at the testbeam area. We are connected to it locally by ethernet cable (hut --> switch --> EUDAQ Pc).
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 18.104.22.168
if rdesktop does not work, do :
ssh -X email@example.com
Run numbering, folder names.
The run number is defined in
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)
Example of configuration file, see it in:
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
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.
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.