Closed eflumerf closed 2 years ago
Comment by @bieryAtFnal on 2014-04-17 13:45:02
The generation of the message probably won't take too long (say 4 hrs). Adding a flag to the data to indicate the problem would be noticeably more work if the infrastructure to flag events needs to be added (say 32 hours)
Comment by @bieryAtFnal on 2014-04-18 14:18:34
Related to Redmine Issue 5958.
Comment by @eflumerf on 2019-04-09 18:51:48
I've started implementing this feature on artdaq:feature/3186_SMEM_FragmentIDChecking.
Comment by @eflumerf on 2021-01-21 20:22:11
I have added fragment_id and expected_fragment_ids bookkeeping to DAQInterface on branch artdaq-utilities-daqinterface:feature/3186_BookkeepFragmentIDs. I have tested this using the simple_subsystems and complex_subsystems simple_test_configs.
Duplicate
This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/3186 (FNAL account required) Originally created by @bieryAtFnal on 2012-12-18 14:37:37
I believe that we should have the ability to see a MessageFacility warning or error message for each event that has duplicate fragment IDs or fragment IDs out of range, and I don't think that we want the program to stop when this happens. I suspect that this will require changes to the RawEvent and EventStore classes, and possibly to builder.cc. (It's not clear to me at the moment where the MF message should be created - in the library or the application code.)
Also, there should probably be some flag in RawEvent that we can use downstream to see that such an event has this data corruption.