may someone can give me a short description
of the different TICK_STATE types, to give me a better understanding of
there meaning:
Thanks,
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/17/2010 10:14 PM
Betreff:
Re: [certi-dev]
Time advancement
Gesendet von:
address@hidden
2010/11/17 Michael Raab <address@hidden>:
>> 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?
Yes and No.
Yes because when the Federate process returns from tick call then
the RTIA::tick_state must be NO_TICK.
However, the RTIA::tick_state may be something else while RTIA process
goes to handle something else (RTIG message) while a tick is pending
on the federate side.
When you want to make the Federate wait (but you want to give a chance
to RTIA process to handle some callbacks from RTIG) then RTIA is sending
some TICK_REQUEST_XXX back to libRTI (with RTIA::tick_state NOT reset
to NO_TICK).
At this point libRTI will send some Tick_Request_Next message to RTIA
(until the timeout expires).
I attach a not too wrong MSC image for that case.
The real picture of those "process state" should be modelled
with some
network of timed automata, I'll try something like that but this
may not be very soon...
>> 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.
A synchronization point may be used for that too no?
Using this may be observer does not have to be regulator?
> Once all models are there, the observer disables its regulation role,
stays
> passive and logs the progress of the simulation.
It may log the progress even if it is constrained and/or regulator
the only thing to add is some time advancing request (TAR/TARA/NER/NERA).
> So it's hard for me the change something with this logic...
When there is no observer, is the simulation running OK?
> Thanks for your support,
I'll try my best to "unstuck" you but like I said before debugging
time advancing mechanism
is... time consuming... unfortunately I'll have to delay my quest for
a couple of days.