1 / 8

Multistep Runs with ROD Crate DAQ

Multistep Runs with ROD Crate DAQ. Murrough Landon, QMUL. Outline: Overview Implementation Comparison with existing setup Readout Status ModuleServices API change Next Steps Demo?. ROD Crate DAQ Controller. Derived from ROS Software

yered
Download Presentation

Multistep Runs with ROD Crate DAQ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multistep Runs with ROD Crate DAQ Murrough Landon, QMUL • Outline: • Overview • Implementation • Comparison with existing setup • Readout • Status • ModuleServices API change • Next Steps • Demo?

  2. ROD Crate DAQ Controller • Derived from ROS Software • Application framework implementing the run state transition skeleton • Implemented as set of plugin libraries, configured via database • Set of ReadoutModules with DataChannels responsible for reading data (analogous to ROBins with input links). • L1Calo implementation • configL1Calo package: schema and data access library providing pluging for our L1CaloReadoutModule subclass • readoutModule package: implementation of module and data channel classes and a “crate” class for common actions at the start of each state transition: • L1CaloReadoutModule • L1CaloDataChannel • CrateSetup • dbFiles package: script to generate RCD DB objects Murrough Landon, QMUL

  3. RCD Implementation Murrough Landon, QMUL

  4. RCD Controller: Pros and Cons • Pro • Standard, supported solution for detectors ROD (and other) crates • Hopefully less maintenance and easier use of new features • Implements readout/monitoring/histo publishing within the framework, also interrupts, database access (not COOL yet?) • Allows multiple readouts during the RUNNING phase of multistep runs (compared with one readout per step at present) • Con • Database requires lots of objects: generate them all from the hardware description (hw/*_crates.data.xml) but then harder to customise individual crates - eg to add applications such as “kickers” • Less flexible: no direct access to RC skeleton • Represents a change from what we are used to Murrough Landon, QMUL

  5. Readout Data • Software • Separate crate_readout program no longer required • Start/stop readout should be better synchronised with state transitions • Format • Data from one crate looks like a ROS fragment, contains one ROB (and ROD) fragment per module • Using “TDAQ beam crate” source ID at the moment (0x700000) • Should add crate ID to this at ROS level, crate and module IDs at ROB/ROD level? • No need for existing one word buffer header (or extended crate header?) but keep rest of the formatted buffer contents • Monitoring • Use -k RCD -v rcd-<crateName> • Existing standalone monitoring programs need to use eformat to locate ROD fragments within the ROS fragment • But GNAM can easily provide a vector of ROD fragments Murrough Landon, QMUL

  6. Present Status • Implemented and tested (OK) • Actions at run state transitions (USA15 and RAL) • Publishing status to IS • One readout at state transitions and many readouts when RUNNING • Problems • See a few “ROS” errors building events (high rate?) • When running, need a way to know if a new event is available • (at present the DataChannel just sleeps a bit) • To be done • Test elsewhere than USA15 (eg with more modules at RAL) • Modify monitoring programs to slightly different packaging of formatted readout buffers Murrough Landon, QMUL

  7. ModuleServices API Change? • Issue • DataChannel has poll() method to see if data is available • (alternatively can use interrupts) • If true, RCD will call DataChannel::getNextEvent() • But at the moment the DataChannel has no way of knowing if PPM or ROD (or DSS?) has a new event available (for other modules its not a problems as status information is always available) • Suggestion • Add a generic isDataAvailable() method to moduleServices API • Only needs a real implementation in PPM, ROD (and DSS?) Murrough Landon, QMUL

  8. Next Steps • Soon • More tests, adapt PPM monitoring and try Tile tests • Try out at other sites, after a few dbFiles mods: • partitions: Partition  PartitionRcd • segments: partition_segments cut down partitionRcd_segments • Include partition_genrcd.data.xml instead of existing crate segments • Fairly soon • Implement moduleServices API change, along with connect() method in preparation for forthcoming run control changes • Not long after • Would like to move to RCD as our standard • NB simulation controller remains in the old style for now Murrough Landon, QMUL

More Related