artdaq_demo  v3_04_00
Class List
Here are the classes, structs, unions and interfaces with brief descriptions:
[detail level 12]
oNanonymous_namespace{AsciiSimulator_generator.cc}
oNanonymous_namespace{genToArt.cc} [external]
oNanonymous_namespace{shared_memory_reader_t.cc} [external]
oNanonymous_namespace{TransferWrapper.cc} [external]
oNanonymous_namespace{xmlrpc_commander.cc} [external]
oNart
|oCSource_generator< artdaq::detail::SharedMemoryReader< demo::makeFragmentTypeMap > >Specialize an art source trait to tell art that we don't care about source.fileNames and don't want the files services to be used
|\CEventReporterOutputAn art::OutputModule which does nothing, but reports seen events and their fragments. This module is designed for debugging purposes, where writing events into ROOT files or sending events down stream is not necessary
oNartdaqThe artdaq namespace
|oCNthEventPolicyAn example RoutingMasterPolicy which redirects every Nth event to a desginated destination. Other events are Round-Robin'ed to the other configured destinations
|\CNthEventTransferDemonstration TransferInterface plugin showing how to discard events Intended for use in the transfer_to_dispatcher case, NOT for primary data stream!
oNdemoThe artdaq_demo namespace
|oCASCIIDumpAn art::EDAnalyzer meant for decoding demo::ASCIIFragment objects
|oCCheckIntegrityDemonstration art::EDAnalyzer which checks that all ToyFragment ADC counts are in the defined range
|oCRootApplicationProvides a wrapper for displaying ROOT canvases
|oCToyDumpAn art::EDAnalyzer module designed to display the data from demo::ToyFragment objects
|oCWFViewerAn example art analysis module which plots events both as histograms and event snapshots (plot of ADC value vs ADC number)
|oCGetPackageBuildInfoWrapper around the demo::GetPackageBuildInfo::getPackageBuildInfo function
|oCAsciiSimulatorGenerates ASCIIFragments filled with user-specified ASCII strings
|oCToySimulatorToySimulator is a simple type of fragment generator intended to be studied by new users of artdaq as an example of how to create such a generator in the "best practices" manner. Derived from artdaq's CommandableFragmentGenerator class, it can be used in a full DAQ simulation, obtaining data from the ToyHardwareInterface class
|oCCommandPacketStruct defining UDP packet used for communicating with data receiver
|oCUDPReceiverAn artdaq::CommandableFragmentGenerator which receives data in the form of UDP datagrams
|\CMisbehaviorTestA test RoutingMasterPolicy which does various "bad" things, determined by configuration
oCNthEventAn art::EDFilter module that passes one out of N events
\CToyHardwareInterfaceJCF, Mar-17-2016: ToyHardwareInterface is meant to mimic a vendor-provided hardware API, usable within the the ToySimulator fragment generator. For purposes of realism, it's a C++03-style API, as opposed to, say, one based in C++11 capable of taking advantage of smart pointers, etc. An important point to make is that it has ownership of the buffer into which it dumps its data - so rather than use new/delete, use its functions AllocateReadoutBuffer/FreeReadoutBuffer