as far as I can see from the log there
is no libRTI call during a callback, moreover the problem looks probably
like a bug in tick handling.
In RTIA of the observer federate the
following things happen.
- tick_request is handled (min =0.1
max=0.5)
- tick_state becomes TICK_BLOCKING
- processOngoingTick() is called
- RAV is executed
- tick_state becomes TICK_NEXT
- tick_state becomes TICK_RETURN
- processOngoingTick() is left
- a new tick_request gets handled(min
=0.1 max=0.5)
- but tick_state is already TICK_RETURN,
not NO_TICK as expected
Hope someone has an idea what may cause
this.
Thank you very much,
Michael
Dipl.-Inf. Michael Raab
Fraunhofer-Institut für Fabrikbetrieb und -automatisierung IFF
Virtuell Interaktives Training
Sandtorstr. 22, 39106 Magdeburg, Germany
Telefon +49 (0) 391/ 40 90 122
Telefax +49 (0) 391/ 40 90 115
address@hidden http://www.iff.fraunhofer.de
oder http://www.vdtc.de
Von:
Eric Noulard <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
11/16/2010 04:32 PM
Betreff:
Re: [certi-dev]
Time advancement
Gesendet von:
address@hidden
2010/11/16 Michael Raab <address@hidden>:
> As far as I can see I only call tick(0.1f, 0.05f) once every loop
in the
> main loop of the observer.
> The only callbacks I handle are:
>
> - receiveInteraction
> - reflectObjectValues
> - removeObjectInstance
> - timeConstrainedEnabled
> - timeRegulationEnabled
The callback does not really matter, what matters is
which libRTI/RTIambassador calls do you do
from **WITHIN** those callbacks.
> Any ideas on how to track that issue down?
1) Look at the code of each callback and examine which call to libRTI
you do.
2) Look where SpecifiedSaveLabelDoesNotExist could be raised.
> Which logging levels would you propose?
In the Observer federate context:
RTIA_MSG=D
RTI_EXCEPTION=X
CERTI_EXCEPTION=X
and may be
RTIG_MSG=D
You shoud see the interleaving of message which raise the exception.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org