certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Time advancement


From: Michael Raab
Subject: Re: [certi-dev] Time advancement
Date: Wed, 17 Nov 2010 19:39:59 +0100

> We will have to seek why _tick_state is not reset to NO_TICK in this case,
> there should be something implicitly broken here.

To understand that correctly, when tick returns control to the application, tick_state should be NO_TICK in each case, correct?

> As far as I remember your description the Observer is
>       regulator
> BUT not constrained

> Would you be able (for the sake of the inquiry)
> to try to make it constrained to?
> or not regulator ?
> or not contrained AND not regulator ?

The observer federate is regulator at the start of the simulation. The idea behind is to ensure that none of the simulation models can advance simulation time before we can be sure that all models have joined and are well initialized.
Once all models are there, the observer disables its regulation role, stays passive and logs the progress of the simulation.
So it's hard for me the change something with this logic...
 
Thanks for your support,
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


address@hidden schrieb: -----
An: CERTI development discussions <address@hidden>
Von: Eric Noulard
Gesendet von: address@hidden
Datum: 11/17/2010 05:33PM
Betreff: Re: [certi-dev] Time advancement

2010/11/17 Michael Raab <address@hidden>:
> Hi,
>
> 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

We will have to seek why _tick_state is not reset to NO_TICK in this case,
there should be something implicitly broken here.

I'll try to follow that path myself, but as usual with time management
and tick-ish things
this may not be easy...

> Hope someone has an idea what may cause this.

As far as I remember your description the Observer is
       regulator
BUT not constrained

Would you be able (for the sake of the inquiry)
to try to make it constrained to?
or not regulator ?
or not contrained AND not regulator ?


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

--
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]