Overview We succeeded in using Slice Test DAQ

  • Slides: 12
Download presentation
Overview • We succeeded in using Slice Test DAQ code to take test beam

Overview • We succeeded in using Slice Test DAQ code to take test beam data, combining chamber and trigger trackfinder data through an XDAQ Event Builder. • We handled some big problems in 2003! – – C++ VME interface and initialization Chamber + trackfinder event building XML configuration Data unpacking and ROOT analysis • For 2004, we need maintenance and extensions to all of the above, plus: – – – Run Control Optimize performance Conditions Monitoring Integration with HCAL?

Data Unpacking • Successful, thanks to a bunch of people, notably Alex, and UCLA

Data Unpacking • Successful, thanks to a bunch of people, notably Alex, and UCLA guys. • It works by using bit shifts and masks to expand the binary fields into integers stored in memory. • But using C bitfields might be better! – – Much faster Easier to maintain Can easily pack as well as unpack But probably less portable • I put a version of Data. Format which uses bitfields into ORCA.

Ways to Unpack Data Class DDUHeader { int unpack_header(unsigned short * buf) { //

Ways to Unpack Data Class DDUHeader { int unpack_header(unsigned short * buf) { // L 1 event number (24 bits) lvl 1 num = (buf[2]|(0 x 000000 ff&buf[3])<<16); // bx number (12 bits) bxnum = (buf[1]&0 x 0000 fff 0)>>4; } int lvl 1 num, bxnum; }; Class Mu. End. DDUHeader { unsigned s_link_status : 4; unsigned format_version : 4; unsigned source_id : 12; unsigned bxnum : 12; unsigned lvl 1 num : 24; unsigned event_type : 4; /// should always be 5 unsigned bit 64 : 4; …. }; Used by just casting the pointer to the data buffer, so faster.

Event Building • Integration with Trackfinder at Test Beam was easy! – Ichiro’s “FED”

Event Building • Integration with Trackfinder at Test Beam was easy! – Ichiro’s “FED” class interface to the EVB was excellent. We need it again. • But EVB couldn’t keep up with full data rate! – – We couldn’t read in the chamber data fast enough Was the problem Data. Format? EVB? I’ll look at trying to find bottlenecks Once we scaled back the trigger rate, everything was OK. • Trackfinder and chamber data synchronized!

EVB + ORCA Filter Units • Peter Kreuzer (UCLA) and the DAQ group would

EVB + ORCA Filter Units • Peter Kreuzer (UCLA) and the DAQ group would love to have an ORCA job running online, to simulate the Level 3 trigger. • Peter & Rick added EMU TB code to ORCA release, and can reconstruct test beam data. • Now Peter can start working on a standalone Builder Unit – Filter Unit link. • Problems now: – XDAQ just starting to be ORCA-compatible – One there is an ORCA-capable EVB, we still need to adapt in Ichiro’s EVB interfaces. – ORCA output data artificial and don’t really reflect hardware • There’s one readout for strip data objects (“digis”) and one for wire data. Completely unrealistic, and causes some complication with real data. • Rick needs to fix this in ORCA (not urgent, but important)

Online Monitoring • Hans Wenzel (FNAL) is adapting CDF’s system for our use •

Online Monitoring • Hans Wenzel (FNAL) is adapting CDF’s system for our use • Pushes histograms out to servers for users to connect to and access • We just need to to add the hooks in the EVB – Before and after filtering • Then Andrei & Victor can define the histograms.

HCAL? • Wesley has brought up the idea of running a combined testbeam (when?

HCAL? • Wesley has brought up the idea of running a combined testbeam (when? ? ). • Therefore, at the risk of sounding unreasonably demanding, I think we should design our system with the requirement that HCAL and EMU be completely integrated.

HCAL Integration: my gut feelings • • • Run control: theirs or RCMS EVB:

HCAL Integration: my gut feelings • • • Run control: theirs or RCMS EVB: ours Conditions: something common Output data: ours ORCA integration – I’ve taken up some responsibilities for ORCA Calo software, too, so I’ll see to this.

Appendix Alex Tumanov Rice University

Appendix Alex Tumanov Rice University

Run Control (Work in Progress) • Graphical User Interface Run Control – Java based

Run Control (Work in Progress) • Graphical User Interface Run Control – Java based tool – Used to control xdaq DAQ – Potentially limitless board diagnostic functionality (every register accessible) • Would like to test with data taking during slicetest week at UF • Ichiro’s working on updated version of GUI

Cosmic Test Jan 2004 • THANKS !!! to UF people for accommodating us and

Cosmic Test Jan 2004 • THANKS !!! to UF people for accommodating us and preparing the setup (several weeks work) • Would like to take cosmic data using new DAQ chain • Possible steps to develop during this test: – Make sure that the DAQ is robust under different circumstances (recent updates to software, rates? ) – Test Run Control GUI – Possibly test new configuration database (Valery Sytnik)

What we want to achieve • Would like to leave a robust working version

What we want to achieve • Would like to leave a robust working version of Peripheral. Crate. Controller with run control GUI • Get input/feedback on performance of the DAQ