glehmannmiotto
commented
2 years ago No run should start with endpoints not in running (0x8) state. The timestamp may be completely off. So I think that the severity is appropriate.
Giovanna
———————- CERN EP/DT-DI
On 18 Mar 2022, at 21:43, bieryAtFnal @.***> wrote:
In testing of dunedaq-v2.10.0 at ICEBERG with real HSI/TLU electronics, I've noticed messages like the following in the HSI logfile:
2022-Mar-15 12:04:26,459 ERROR [virtual void dunedaq::timinglibs::HSIReadout::do_hsievent_work(std::atomic
These errors seem to happen at the beginning of a run and then stop.
If these are a normal part of the startup of each run, maybe we can reduce their severity somehow? Of course, if they happen during a run, I expect that we will still want them to be errors.
— Reply to this email directly, view it on GitHubhttps://github.com/DUNE-DAQ/timinglibs/issues/47, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD6SRUYVIXVP43EMAYOM4BTVATTGFANCNFSM5RC3VTHA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.Message ID: @.***>
bieryAtFnal
strilov
In testing of dunedaq-v2.10.0 at ICEBERG with real HSI/TLU electronics, I've noticed messages like the following in the HSI logfile:
These errors seem to happen at the beginning of a run and then stop.
If these are a normal part of the startup of each run, maybe we can reduce their severity somehow? Of course, if they happen during a run, I expect that we will still want them to be errors.