Hello Zheng,

thanks for your attached test files.

Your solution works but I'd like to examine the problem
in more detail, because
a)
I cannot reproduce the error on a linux system (g++)
b)
I wouldn't replace the original "pointer solution" through a
memory copy mechanism.

You said when executing my test script you get the exception:
Caught unknown exception.

This means that the invocation of the RTI service
enableTimeRegulation(*par1, *par2) do not work properly.

Your assumption was that the conversion of the
parameters within the function mscalar2fedTime is incorrect.
That's why you switched to the concept "call by value".

Please tell me which value have par1 and par2 directly
before calling enableTimeRegulation. Also the values
of plhs[0] and plhs[1] after the entrance are important.
It would be helpful if you can analyse what happens
in the function mscalar2fedTime.

Can you give me the output of the compilation
process of the toolbox in cvs with all warnings enabled?

It is very importent to know the reason for this
behaviour, because nearly all conversion within the toolbox
are done by reference, not by value.

Does Windows know a something like errno?

I'd like to appreciate your help.

because upload size limit is set to 512 kB, I divide my test files into three parts: iconv.rar, libxml2.rar, matlabTest.rar,
this file is the second part.

(file #15812)

Hi Zheng ;),

I now noticed what you have done, you instantiate
theFederateTime and theLookahaed directly.

That's why you have to modified mscalar2fedTime. This is
a dangerous step because all other functions using mscalar2fedTime
have to be modified too and as I already mentioned it does not
really fit in the toolbox concept.

My problem is the following: I can execute file #15799 without
any problems. Can you please execute the small Matlab script
and tell me your expierences.

After that wwe will find out were the problem lies.

Hi Zheng,

thanks for your work, but I do not think that your
modifications are correct.

Something to the function interface within the toolbox:

If you are calling enableTimeReg(val, val) within
Matlab (enableTimeReg.m)
than sometihing like the following is executed:

except = rti(8020, theFederateTime, theLookahead);

You see, we call into the mex-file rti with three
arguments a number corresponding to the HLA
service number and to additional parameters required by
this service.

In rti.cpp you find in line 3383 the mex gateway function

void
mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {

  ....

This is the entry function for every mex-file. Please look at
the function interface. The same interface is used for all
service functions starting with the tag m2 (stands for
Matlab to).

Back to the service enableTimeRegulation:

When executing the m-file enableTimeReg we call into the mex
file with

except = rti(8020, theFederateTime, theLookahead);

Then we enter the mex file at line 3383 with

void
mexFunction(int nlhs, mxArray /*plhs[], int nrhs, const mxArray *prhs[]) {

After that we find the correct m2 function, in our case
m2enableTimeReg, with the help of the submitted service number
in a big switch construct.

/* Time Management Services */
case  8020: m2enableTimeReg(nlhs,plhs,nrhs,prhs); break;

All parameters excluding the service number passed
through the mex gateway function are now transferred directly
to the m2enableTimeReg function. That means of course
that the function interface of m2enableTimeReg(...) have to
be the same as the function interface of the mex gateway
function. Look at the other m2Something :) functions, they
have all the same function interface.

mscalar2fedTime returned a pointer because all toolbox
conversion functions return pointers. So this fits
not really in the toolbox concept.

Please answer me the following questions:

Do you use the Matlab-Toolbox version from the cvs or
the version from the download section?

Did you execute my attached Matlab #15799 script with a clean
Matlab Toolbox? Did you get the same errors as before?

If yes, we have to find out why, because I get no errors
when executing the attached script.

Thanks for your help I/we need your help. Perhaps at
first start to answer my questions.

So long
Christian

Hi.

Sometimes it is very useful to attach test files etc.
at the tracker.

So erveryone can get an fast overview or run own test
on basis of your attached files.

So long,
Christian

I test the function enableTimeConstr and enableTimeReg in MatlabHLA_Toolbox. the enableTimeConstr runs OK and timeConstrEnabled is called, but enableTimeReg still does not work, it throws an error 'caught unknown exception' . the codes in controlFed_wTime demo is as follows:
  ...
  disp('Init time management features.')

  e = enableTimeConstr
  e = enableTimeReg(tStart, h)
  e=modifyLookahead(h) %My code
  e = enableAsyncDeliv

  ...

I also write a C++ demo to test the the function enableTimeConstr and enableTimeReg, and find they are all runs OK.

Bug 23460 has been fixed in CVS.

Zheng,

Could you try to use either
CERTI CVS tree
(or the following beta tarball
 http://download.savannah.gnu.org/releases/certi/beta/certi-3.2.8cvs-Source-eric-04jun2008-18h20.tar.gz)

recompile and
retry?

The trouble was not federate that trying
to use zero lookahead but that the
enableTimeRegulation API does not set lookahead :=)

so if your federate use

enableTimeRegulation
+
modifyLookahead

this is OK, since modifyLookahead API is not buggy.

if you use:
enableTimeRegulation

you may have zero-lookahead issue even if your federate
does not advertise zero-lookahead.

my proposal to change lookahead is a workaround.

And guess what, Billard always use modifyLookahead to set up
his lookahead...

I think the current bug is related to
the newly submitted enableTimeRegulation bug (see dependency list).

Would you try to modifyLookahead with a non zero value
and retry?

Hello Zheng,

May be you can try to run the C++ controller/process
demo and check if it runs OK on your config.
If this is the case then may be the trouble is
within MatlabHLA layer.

Hi Christian,

>In what context appear this behaviour?
> Do you know the sources?

This is a 2 federate config, which use Federation synchronization.
Both are regulating and constrained.

They synchronize cleanly then enter a TAR waiting for TAG loop
and none of them get TAG.

The source of the federate are not publicly available,
the only clue I have is that they seems to have zero lookahead
(inside TimeManagement.cc) but I did not manage to trace
where the lookahead becomes zero yet.

Pierre did implement zero lookahead algo recently,
so zero lookahead should work but I had
to patch this source code area because of some roundoff trouble
with small lookahead.

I'm investigating the issue but I would like to tell you
that you may encounter the same issue from within
MatlabHLA_Plugin.

Hello Zheng,

I can't reproduce the problem too. I tested with certi-2.6 and with the current certi cvs version.

At first tell me please what Matlab version you are using.

How do you compile your Matlab Tbx.

My steps are:
1) Get and install CERTI
2) verify installation (start rtig, billard, ...)
3) get MatlabHLATbx
4) change directory to ~/yourMatlabHLATbx
5) make && make install
   -> the whole tbx is copied to
      ~/yourMatlabTbx/MatlabHLA13_v0.5
6) copy the toolbox to the path ~/where_ever_you_want
7) open matlab, add the path ~/where_ever_you_want to
   your Matlab path environment
8) change to the directory
   ~/yourMatlabTbx/demo/TwoLevelController/controlFed_wTime
9) execute controlFed
10) start second Matlab instance
11) change to the directory
   ~/yourMatlabTbx/dem/TwoLevelController/processFed_wTime
12) execute processFed

Normally all should work now.

The both federates realize a closed loop control. The controlFed
computes the control value and the process federate computes
the output value.
See the CERTI HLA_Tutorial for further information (task #6911)

Did you start the second federate?

I'll investigate this right away.