 13 Oct 2004, Konstantin Olchanski, Bug Report, TWIST upgrade bombed...
|
> > The upgrade of TWIST to the latest midas has bombed- we see mevb and mlogger
> > crashes during shared memory data buffer accesses. I am looking into it and I
> > will add information as I figure things out. K.O.
|
|
14 Oct 2004, Stefan Ritt, Bug Report, TWIST upgrade bombed...
|
Agree.
Once you did the modification, please check following situation: Create a fresh
|
|
14 Oct 2004, Konstantin Olchanski, Bug Report, TWIST upgrade bombed...
|
> The upgrade of TWIST to the latest midas has bombed- we see mevb and mlogger
> crashes during shared memory data buffer accesses. I am looking into it and I
> will add information as I figure things out. K.O.
|
|
24 Jun 2009, Konstantin Olchanski, Bug Report, TR_STARTABORT transition, mlogger duplicate event problem
|
> > > We have seen on several daq systems this problem: we start a run and observe that the number of
> > > events written by mlogger to the output file is double the number of events actually collected. Upon
> > > inspection of the output file, we see that every event is written twice. Restarting the run usually fixes
|
|
25 Jun 2009, Stefan Ritt, Bug Report, TR_STARTABORT transition, mlogger duplicate event problem
|
> Stefan suggested implementing a new transition, TR_STARTABORT, issued if TR_START fails. mlogger can use it to cleanup open files, etc, similar to TR_STOP.
>
> This is now implemented. In mlogger, TR_STARTABORT is similar to TR_STOP, but deletes open output files and does not save end-of-run information into |
|
25 Jun 2009, Konstantin Olchanski, Bug Report, TR_STARTABORT transition, mlogger duplicate event problem
|
> > Stefan suggested implementing a new transition, TR_STARTABORT, issued if TR_START fails. mlogger can use it to cleanup open files, etc, similar to TR_STOP.
> >
> > This is now implemented. In mlogger, TR_STARTABORT is similar to TR_STOP, but deletes open output files and does not save end-of-run information into |
|
25 Jun 2009, Stefan Ritt, Bug Report, TR_STARTABORT transition, mlogger duplicate event problem
|
> Are you sure? Only clients that register themselves to receive the TR_STARTABORT transition (via cm_register_transition()) will receive this transition.
>
> As of now, the only client that registers and receives this transition is mlogger.
|
 06 May 2013, Konstantin Olchanski, Info, TRIUMF MIDAS page moved to DAQWiki
|
The MIDAS web page at TRIUMF (http://midas.triumf.ca) moved from the daq-plone site to the DAQWiki
(MediaWiki) site. Links were updated, checked and corrected:
https://www.triumf.info/wiki/DAQwiki/index.php/MIDAS
|
|
12 Feb 2025, Mark Grimes, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
Hi,
I have a manalyzer that uses a derived class of TMFeRpcHandlerInterface to communicate information to
Midas during online running. At the end of each run it saves out custom data in the
|
|
26 Feb 2025, Thomas Lindner, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
Hi,
Sorry, we have been slammed with a couple projects on the TRIUMF side in the past weeks and haven't found time for a
|
|
20 Mar 2025, Konstantin Olchanski, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
> I have a manalyzer that uses a derived class of TMFeRpcHandlerInterface to communicate information to
> Midas during online running. At the end of each run it saves out custom data in the
> TMFeRpcHandlerInterface::HandleEndRun override. This works really well.
|
|
25 Mar 2025, Mark Grimes, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
Hi,
The question was about the TMFeRpcHandlerInterface, not the TARunObject interface. Derived classes of TARunObject do indeed work as expected in our
environment. We have worked around the issue by using an implementation of TARunObject as well as the (separate) implementation of
|
|
25 Mar 2025, Konstantin Olchanski, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
> The question was about the TMFeRpcHandlerInterface, not the TARunObject interface. Derived classes of TARunObject do indeed work as expected in our
> environment. We have worked around the issue by using an implementation of TARunObject as well as the (separate) implementation of
> TMFeRpcHandlerInterface.
|
|
26 Mar 2025, Mark Grimes, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
This was exactly the question, should I expect it to run? There's no point in the HandleBinaryRpc method offline, but there's an argument that the HandleBeginRun/HandleEndRun
methods have a use.
I have the answer and we have a workaround, thanks.
|
|
28 Mar 2025, Konstantin Olchanski, Forum, TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file
|
I do not understand what you are doing. If you are offline, there is no TMFE singleton instance,
there is nothing TMFeRpcHandlerInterface to attach to, there is nobody to call TMFeRpcHandlerInterface methods.
|
|
25 Feb 2021, Lars Martin, Forum, TMFePollHandlerInterface timing
|
Am I right in thinking that the TMFE HandlePoll function is calle once per
PollMidas()? And what is the difference to HandleRead()? |
|
25 Feb 2021, Konstantin Olchanski, Forum, TMFePollHandlerInterface timing
|
> Am I right in thinking that the TMFE HandlePoll function is calle once per
> PollMidas()? And what is the difference to HandleRead()?
|
|
26 Nov 2024, Nick Hastings, Bug Report, TMFE::Sleep() errors
|
Hello,
I've noticed that SC FEs that use the TMFE class with midas-2022-05-c often report errors when calling TMFE:Sleep().
|
|
26 Nov 2024, Maia Henriksson-Ward, Bug Report, TMFE::Sleep() errors
|
> Hello,
>
> I've noticed that SC FEs that use the TMFE class with midas-2022-05-c often report errors when calling TMFE:Sleep().
|
|
27 Nov 2024, Konstantin Olchanski, Bug Report, TMFE::Sleep() errors
|
> [tmfe.cxx:1033:TMFE::Sleep,ERROR] select() returned -1, errno 22 (Invalid argument).
The very original copy of this function had an error and was spewing out this error quite often,
|