Please find attached my test project



(file #16125)

Hi Eric,

the enablingTimeRegulation procedure in my application looks like this:

void TimeManagement::enableTimeRegulation( double theFederateTime, double theLookahead )
{
// convert times...
RTIfedTime fedtime(theFederateTime);
RTIfedTime lookahead(theLookahead);

HLAManagement::GetRTIAmb()->enableTimeRegulation(fedtime, lookahead);

TimeManagement::_regulationRequestPending = true;

while(TimeManagement::_regulationRequestPending)
{
HLAManagement::tick(0.1, 1.0);
}
}

where the timeRegulationEnabled callbacks causes a local update of simulation time and of course unsetting the flag regulationRequestPending.

QueryFederateTime tells me that the current fed time is zero (as i would expect).

I will to provide you a test app, but i will be in vs2005.net.
OK for you?

By the way, could you provide the full HLA1.3 specification?

Michael

Good morning,

i just tried to use NER instead of TAR, but it comes to the same results. Timesteps with a minimum length of lookahead are possible, shorter steps cause an InvalidTimeException.

Michael

Me again,

at some time ago I tried to explain
some conservative sync algorithms in a seminar
at our university. The talk is in German. So
probably only Michael can use it really.

Look at pages 65(51)... there one can find some
"animated" slides.

Since CERTI implements a nullmessage algorithm
it could be useful for you.

Here's the link:
http://www.mb.hs-wismar.de/~stenzel/talks/20070710_vortrag_distSim.pdf

Thats the behavior that i've expected ( 2. ).

But to me there seems to be another problem:

i do the following:

create fed
join fed
enable asyn delivery
enable time regulation (0.0, lookahead)
enable time constrained

If i try to advance simulation time and choose a timestamp that is lesser than is between currentTime and currentTime + lookahead then i get an InvalidTimeException.

To lookahead specifies that i cannot generate events (attribute update, interactions, ...) for timestamps that are lesser that currentTime + lookahead. But time advancement to a point between currentTime and currentTime+lookahead should be possible and is possible in other RTI implementations (for example dmso).

What do you think?

Michael

No prob, do the following

rtiamb.enableTimeConstrained()
rtiamb.enableAsynchronousDelivery()

then tick until you get the callback
timeConstrainedEnabled()

Hi Micheal,

the reason for taht behaviour is described somewhere below
in this thread.

Probably you have no fresh cvs version. Please checkout
a new one.

If you use the current version available in the download section
you can do the following:

After enabling time constrained with
enableTimeConstrained() do a
enableAsynchronousDelivery().

After that you will get th ecallback.

The background is the following:
In the current cvs version the callbacks
timeCOnstrainedEnabled and timeRegulationEnabled
are treated as commands. The versions before treat
these callbacks as ro messages.

And as a rule time constrained federates have to
enable their asynchronous delivery switch to
receive ro messages outside a time advance request.

But as I said we noew treat that callbacls as
commands.

So you should get it. For an example see the federate
test_TRTCCallbacks in the HLA_TestsSuite foler.

So long,
Christian

> Until now U had no success with the new dtest version.

Pretty true.
Lack of time means lacks of testing,
which is just a shame for a test framework :=)

I will certainly make a dtest 0.5.1 which fix
the install issues with proper dependency checking
at runtime.

> I will make a new try at home. Which python version is
> required, I use 2.4. Should I upgrade to 2.5?

Python 2.4 should be OK.
You "only" require paramiko 1.7.x which in turns
requires pycrypto.

Hi Eric,

now it works! I've made a fresh cvs checkout of dtest,
after that a "full installation" with all externals
and set my envvar PYTHONPATH to the dtest dir.

After that make test works fine for me.

With the dtest-0.5 file from from the download area
I had no luck

You should update your DTest.
I will add version check in order to avoid this
situation and throw a meaning full message instead
of a bare stacktrace.

The script is using dtest-0.5 and up
you local dtest install should predate dtest-0.5 (June, 23 2008)
you may cvs update dtest if it is a cvs tree
or take dtest-0.5 archive:
http://download.savannah.gnu.org/releases/tsp/dtest/dtest-0.5.tar.gz

Note there is ongoing bug for dtest usage:
https://savannah.nongnu.org/bugs/?23721
https://savannah.nongnu.org/bugs/?23720

but you shouldn't face those since you already runned dtest
before.

My opinion is that you may apply the patch
as soon as the corresponding
HLA_TestsSuite/test_TRTCCallbacks passes OK.

I reopened this bug, because of the discussions in
the dev mailing list.

Eric describes the problem:
http://lists.nongnu.org/archive/html/certi-devel/2008-06/msg00024.html
In short: To get the callback Time Constrained Enabled one have to
enable AsynchronousDelivery before ticking outside a timeAdvancerequest (because the federate is time constrained).

After that some others verified the current implementation of CERTI
with other RITs.
http://lists.nongnu.org/archive/html/certi-devel/2008-06/msg00027.html
Here we get the same runtime behaviour like RTI-NG.

But Pierre give the advise to treat the callbacks TRE/TCE as
commands, not as RO messages.
http://lists.nongnu.org/archive/html/certi-devel/2008-07/msg00030.html
So we can avoid the strange behaviour.

Hi Eric,

many thanks for your work. I have taken some free
days with my family, so don't worry to apply the
patch by yourself.

I will study your changes at the end of the next week
in detail.

A short question, the code snippet below (from the attached
patch) inserts the callbacks in the FIFO queue. Here I was
unsure, because there is also a command queue.


+++ RTIA/RTIA_network.cc 10 May 2008 08:15:49 -0000
@@ -326,6 +326,17 @@
         queues->insertFifoMessage(msg);
         break ;
 
+      case NetworkMessage::TIME_REGULATION_ENABLED:
+      D.Out(pdTrace, "Receiving Message from RTIG, "
+      " type TimeRegulationEnabled.");
+      queues->insertFifoMessage(msg);
+      break ;
+      case NetworkMessage::TIME_CONSTRAINED_ENABLED:
+      D.Out(pdTrace, "Receiving Message from RTIG, "
+      " type TimeConstrainedEnabled.");
+      queues->insertFifoMessage(msg);
+      break;

As I told you in another message
 I made some change in NetworkMessage.
I'll try to sync your patch with the current tree,
unless you are wanting to do it?

(shouldn't be a lot of work I may try tomorrow).

Hi Christian,

Nice patch, I'm not finished reviewing it but
concerning added NetworkMessage:

NM_Time_Regulation_Enabled::NM_Time_Regulation_Enabled() {
        this->name = "TIME_REGULATION_ENABLED";
        this->type = NetworkMessage::TIME_REGULATION_ENABLED;
        isDated =true;
}

you should not set isDated to true in the constructor.
the "isDated" field will be automatically set
whenever the setter
NetworkMessage::setDate(double date) is called.

this way it is easy to implement timestamped or not timestamped
variant of some network message.
If the sender call setDate before sending the message
then message isDated.

NetworkMessage::serialize
NetworkMessage::deserialize

will automatically handle timestamped or not timestamped message.

I may switch isDated to be a private field, this way a
daughter class won't be able to set it.

Concerning RTIG or local RTIA handling I think
RTIG is the conservative solution, but off course local RTIA
callback would be more efficient (avoid RTIA<->RTIG roudnd-trip)

I think we should go on with the current idea of RTIG
callback (which in this case is just a acknowledge)
unless we imagine another scheme with ensured safety property.

Currently if the NM_Set_Time_Constrained was lost
Federate may consider to be Constrained but RTIG won't
handle it this way.

I had a conflict in RTIA_network.cc because your local
tree may not be up-to-date (there have been a lot of check-in
last days)

I'll work on your patch keep you posted.

Hi,

the attached patch file contains a possible solution.

I've tested with test_TRTCCallbacks from the HLA_TestsSuite folder.



(file #15632)

Hi Christian,
Go ahead.
I really don't know why this bug/feature missing
was dormant for so long.

Enable Time Contrained/Regulation services have HLA 1.3 API but HLA 1.0 behaviour: federate has to time advance until the request is successful, and the callbacks are not used.