Look into adding state transition calls in driver.cc
It would probably be useful to include "start" and maybe "stop" transition calls in driver.cc. Or, maybe we make a copy of driver that supports state transitions.
I thought that we had already talked about doing this, and it looks like it is included in ds50Driver.cc.
If driver called start() and stop() for the configured FragmentGenerator, then it might be more useful in testing the code that will be used in a full artdaq system.
#1 Updated by John Freeman over 4 years ago
- Status changed from New to Resolved
- Assignee set to John Freeman
- % Done changed from 0 to 100
- Estimated time set to 4.00 h
With artdaq commit 9b63c1b8523bb459260aeb6608bab38daf330631, if the generator supplied to the artdaqDriver program via the FHiCL document is not just an artdaq::FragmentGenerator but an artdaq::CommandableFragmentGenerator, it's now the case that the generator's StartCmd function is called before getNext starts being called, and after the final call to getNext, StopCmd is called. As far as the arguments taken by these transition functions, they're set in this snippet:
int run = pset.get<int>("run_number", 1); uint64_t timeout = pset.get<uint64_t>("transition_timeout", 30); uint64_t timestamp = 0;
So it's possible to override the (reasonable) defaults for run # and transition timeout in the FHiCL code, but the timestamp is hardwired to 0. One can see the new driver code in action if artdaq is built off of the above commit (or newer) and artdaq-demo is built off of commit 639688de3e81a96cf63fdceb399e916bc4a5ef7f (or newer), and after building artdaq-demo and setting up its environment, from build_artdaq-demo one simply runs:
artdaqDriver -c fcl/driver.fcl