Present state and (possible) evolution

DAQ ECAL testsDAQ ECAL tests

MenuMenu

2002 experience

Raw data format

Trigger rate measurement

New electronic readout

XDAQ or not XDAQ ?

2002 experience2002 experience

● What worked fine

● What should be improved

● What did not worked properly and must be cured

What worked fineWhat worked fine

● Camac RO ( except one RAID processor that had to be replaced after power cut )

● Fastbus RO ( for how long ? )● VFE RO by ROSEs - in the 9 modes: gains 33, 9, 5, 1, auto

temperature, dark current, ADC ref, temp ref - no synchronisation lost on the optical links● Run control, new features added : - FPPA control - ROSE control ( latency, # of samples, DAQ/DEBUG mode ) - laser control ( light intensity ) - beam scan● On flight production of pedestals ( very few runs to be

manually reprocessed )

What can be improvedWhat can be improved

● Run a mirror for the MySQL run DB to be safe in case of power cut in Meyrin or Prevessin ( done )

Try to be less sensitive to AFS failures Find a solution to avoid the klog constraints

● Java monitoring : - increase the speed - improve the visualisation for beam scan runs

● History plots introduced for the 1st time. - allow pedestals-laser stability and irradiation/recovery

checks. - more interactivity needed.

History plot exampleHistory plot example

The most important problemsThe most important problems

● CCT processor reading ROSEs crashes - ~once a day, now even sometime worse. - reason currently under investigation, we replace in one

processor used in b-11 the (remote) release by the last official release installed on a new disk

recently bought ( 12 days without crash ).

● Missing or incomplete raw data runs on CASTOR. - understood ( file name used for detecting if data has

been sent to pre-processing problem ).

Raw data formatRaw data format

At present: a la Zebra simple linear structure

Avantages over OO storage:● Allow event dump showing the data blocks as they come

from the hardware (mandatory in a test beam environment)

● Allow a very simple program to read it. No maintenance problem over long period of time. Can be easily (and has been) converted in C, C++, Java

● Avoid loosing all the data in case of harware or software crashes

In the future?

Trigger rate (1)Trigger rate (1)

RO time was measured to be :

- 1.5 ms for 100 crystals 25 samples

- 0.8 ms for 100 crystals 13 samples

Trigger rate (2)Trigger rate (2)

... but these performances were measured with the

present electronics,

studies have to be carried out for the new design

(preliminary estimation shows no performance degradation).

Processors and ComputersProcessors and Computers

New electronic Read OutNew electronic Read Out

Control from CCS/FEC to FE/CCU

Data from FE/Fenix to DCC

XDAQXDAQ

Attempt to answer a question never clearly addressed :

Will we use XDAQ in H4 test beam ?

Benefits,

Constraints,

Cost ( work and money )

XDAQXDAQ

What is XDAQ ?

“XDAQ is a software package to address the task of creating distributed systems in environments with efficiency, configurability and scalability requirements.

Much like a ship can be used to transport cargo and people from one continent to another, XDAQ can be used for numerous different data transportation tasks.

It is blind to its application domain.

You can use it in small and large network environments and you can transfer any kind of data.”

The authors (J.Gutleber and L.Orsini)

XDAQXDAQ

Developed by J.Gutleber and L.Orsini,

used by the CMS tracker and muon communities.

Beautiful ideas behind :

- dynamic load of objects and execution of methods

(standard C++ classes)

- easy (re)configuration of the system through xml files

- support for different transport protocols

- and certainly a lot more we have not yet discovered

XDAQ, but... (1)XDAQ, but... (1)

Despite similarities in the software (xdaqWin/RunControl, xdaq.exe/local_rc, TCP/IP used to exchange messages) a major work must be done to go from the present system to XDAQ, with a small benefit for H4 activities.

The benefit coming from re-using software written by other groups (outside ECAL) is not tighten to the use of XDAQ.

Indeed, any software written to add new device RO must be split in (at least) 2 parts :

* access to the device (necessary)

* integration in XDAQ applications (optional)

That's exactly what has been done for the FEC/CCU/xxx

by the (tracker) Strasbourg-Mulhouse team.

We are debugging in Lab 11 the Fenix access using their

software outside the XDAQ framework.

XDAQ, but... (2)XDAQ, but... (2)

XDAQ usage implies to have processors running a

g++ compiler. This is not the case for the CES software

distribution used by our RAIDs 8235.

Support for VME, PCI devices is available. Nothing for

neither Fastbus (obviously) nor CAMAC (unfortunately).

Distribution is available

for Linux and VxWorks

and can be on request made

for Solaris

XDAQ conclusionsXDAQ conclusions

We must take a decision between keeping our on purpose DAQ or moving to XDAQ.

If the move to XDAQ is decided:● CAMAC RO can certainly be easily implemented.

But we have to buy a new processor.● Forget Fastbus. Problem for EE?● Spend a large amount of time to re-do what already

works,try to integrate existing SW ie: main Run control, local Run control, Table control, Event dump, Monitoring, Event building in the new frame, work which provides much less fun than the (mandatory) work on the requested

improvments and the new electronic RO.

ConclusionsConclusions

● From this year experience, the foreseen improvements should insure a smooth precalibration running.

● New software needed to read next year electronics

● XDAQ?