120 likes | 218 Vues
This project involves developing and testing software for event building in XDAQ environments, focusing on communication between detector-dependent software and readout units. Challenges include event synchronization and maintaining compatibility with existing systems. Efforts are underway to streamline the process and improve user experience by automating board signals and configurations. Collaboration among electronics experts is essential for successful implementation and maintenance of the new software.
E N D
Slice Test DAQ Softwarewhat we did in Florida, and what problems may be lurking beneath the surface…
Event Builder Input • GenericFED class encapsulates XDAQ communication between detector-dependent software, event builder readout unit (Ichiro, Rick) XDAQ GUI EmuFED FileReaderDDU GenericFED EmuConfigFED RU HardwareDDU xdaqApp EventReader bool getNextEvent() DDUReader
Event Builder w/Trackfinder • Only need an EventReader::getNextEvent() routine • Writing a routine which reads (destructively) the Sector Processor FIFOs, stores in memory, and parses events • File-reading version already exists (Holger/Darin) • Just need to merge with the HAL interface • After that's done, the XDAQ-ification is easy.
Event Builder Output • Format is ORCA-readable (G. Bruno) Event Header Readout Unit Header (Chamber data: DCC) FED Header (DDU) DDU data FED Trailer Readout Unit Trailer Readout Unit Header (Trackfinder crate) Trackfinder data Readout Unit Trailer Event Trailer
Issues: Event Synchronization • Right now, the Event Builder assumes the events all come in the same order from all inputs • Not always the case: events can get lost • We need to make some phony TriggerInterface for the EVB which tells it which trigger number to do next. Maybe based on the level 1 accepts in the chamber data?
Peripheral Crate Controller • Replaces C routines in cfeb_control • Verified at test crates in Fermilab, UCLA, Florida • Sends same signals to VME as cfeb_control • Practical Advantages: • Sends start and stop signals to boards automatically • User doesn't need to do by hand • Can keep many crates & boards in memory simultaneously • Configuration done in XML (Alex) • Want to hear Valeri’s experience with using it for slow control
Peripheral Crate Controller Singleton CrateSetup CCB TMB ALCTController VMEModule Crate DAQMB VMEController DDU MPC
XDAQ Crate Control • Only three buttons: • Configure • Enable • Disable
Issues: Winning market share • Cfeb_control is a huge GUI with a button for almost every subroutine in the system. • Do we need to compete with that? • How else can we get the electronics experts to use (and develop and maintain) the new code?
Issues: Maintaining Crate Code? • I claim our code makes the correct VME calls for five kinds of boards. • I don’t claim to understand any board’s VME calls. • Who can provide? • Meaningful names for all those hardcoded register and address numbers? • All boards • Cleanup of vestigal code? • Especially ALCT • This code will be in CMS longer than many of us! • It should correspond explicitly to the hardware manuals • A HAL rewrite may be in order someday
Slice Test Software Summary • XDAQ/C++ Crate Control • Event Data Structure • Including Sector Processor data • Expect to be done soon • Combined Event Building • Just need to deal with event synchronization