Present state and (possible) evolution DAQ ECAL tests

Menu 2002 experience Raw data format Trigger rate measurement New electronic readout XDAQ or not XDAQ ?

2002 experience ● What worked fine ● What should be improved ● What did not worked properly and must be cured

What 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 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 1 st time. - allow pedestals-laser stability and irradiation/recovery checks. - more interactivity needed.

History plot example

The 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 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) RO time was measured to be : ms for 100 crystals 25 samples ms for 100 crystals 13 samples

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 Computers

New electronic Read Out Control from CCS/FEC to FE/CCU Data from FE/Fenix to DCC

XDAQ Attempt to answer a question never clearly addressed : Will we use XDAQ in H4 test beam ? Benefits, Constraints, Cost ( work and money )

XDAQ 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)

XDAQ 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) 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 usage implies to have processors running a g++ compiler. This is not the case for the CES software distribution used by our RAIDs 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 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.

Conclusions ●From this year experience, the foreseen improvements should insure a smooth precalibration running. ●New software needed to read next year electronics ●XDAQ?