Closed eflumerf closed 2 years ago
Comment by @bieryAtFnal on 2019-06-07 18:19:12
I haven't actually started working on the RoutingNetOutput module, but I wanted to capture some diagrams that show the branches that will likely feed into this.
Please see the attached file.
Comment by @bieryAtFnal on 2019-06-12 14:57:55
I've created working/22535_protoDFO_testing branches in both that artdaq_core and artdaq repositories. The merges shown in the attached slides have been done as part of creating these branches. In addition, I've started modifying the code on this branch in the artdaq repo to start demonstrating the prototype DFO functionality. (for example, adding the RoutingNetOutput_module.) There are lots of questions about how to handle things that I'm deferring, for now, in order to have something to test at protoDUNE, and of course, we'll need to come back to those questions.
Comment by @bieryAtFnal on 2019-06-12 15:09:44
I've also created a working/22535_protoDFO_testing branch in the artdaq-utilities-daqinterface repo with tentative changes to DAQInterface to support the RoutingNetOutput_module.
Comment by @bieryAtFnal on 2019-06-20 14:59:12
Uploading a new file with an updated picture of the branches (added working/22535_protoDFO_pduneHacks).
Comment by @bieryAtFnal on 2019-06-26 20:58:52
Uploaded a new document with pictures of branches in various repositories - added artdaq-demo, mpich-plugin, and daqinterface.
This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/22535 (FNAL account required) Originally created by @eflumerf on 2019-05-08 02:26:44
Part of the DFO infrastructure is a DataReceiver application (similar to EventBuilder, DataLogger, and Dispatcher), which receives data from the software triggering system, and determines the destinations on an event-by-event basis.
This could be accomplished by a version of BinaryNetOutput which uses a TokenReceiver class and RoutingPolicy to determine where to send data (triggering Requests to pull-mode BoardReaders).