Mon 15 Nov 2010 06:59:31 AM UTC, comment #25:
Hello,
this bug is not solved and should be remain open. As soon as possible, I will investigate that problem in detail (I think with the start of the new year).
Bye
|
Fri 12 Nov 2010 08:15:04 AM UTC, comment #24:
Christian,
Zheng,
I am doing some pruning in the bug tracker.
Do you think we can close this bug?
Is it solved?
|
Wed 18 Jun 2008 02:10:35 PM UTC, comment #23:
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.
|
Sun 08 Jun 2008 09:09:18 AM UTC, comment #22:
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 third part.
(file #15813)
|
Sun 08 Jun 2008 09:01:57 AM UTC, comment #21:
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)
|
Sun 08 Jun 2008 08:53:59 AM UTC, comment #20:
I try execute file #15799 and find the same problems. but if I execute file #15799 with modified C-mex file rti.cpp, it runs OK.
now I give you me test files.
(file #15811)
|
Sat 07 Jun 2008 07:00:33 AM UTC, comment #19:
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.
|
Sat 07 Jun 2008 06:32:55 AM UTC, comment #18:
Sorry, I made a fault.
For Zheng:
I thought that your changes are the bold ones, but this is
not the case. I noticed it when re-reading my comment.
Something starting with a is printed in bold letters
like *bold letters :). I check your changes again.
|
Sat 07 Jun 2008 06:26:48 AM UTC, comment #17:
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
|
Fri 06 Jun 2008 06:03:00 PM UTC, comment #16:
I have solved this problem,my step as follows:
1 rebuild certi library use certi-3.2.8cvs-Source-eric-04jun2008-18h20.tar.gz) in vc.net 2003;
2 debug the C-mex file rti.cpp, I found the bug lies in :
RTIAMB->enableTimeRegulation(theFederateTime,theLookahead);
so I modify the 'm2enableTimeReg' function and 'mscalar2fedTime' function :
static void
m2enableTimeReg(int nlhs, mxArray plhs[], int nrhs, const mxArray prhs[]) {
RTIfedTime theFederateTime; // supplied C4
RTIfedTime theLookahead; // supplied C4
theFederateTime = mscalar2fedTime(prhs[0]);
theLookahead = mscalar2fedTime(prhs[1]);
try {
RTIAMB->enableTimeRegulation(theFederateTime,theLookahead);
plhs[0] = cstr2mstr("");
}
catch (RTI::Exception &e) {
plhs[0] = cstr2mstr(e._name);
}
catch (...) {
plhs[0]=cstr2mstr("caught unknown exception");
}
//free_fedTime(theFederateTime);
//free_fedTime(theLookahead);
return;
}
//-------------
static RTIfedTime
mscalar2fedTime(const mxArray *mscalar) { // supplied
//RTIfedTime *theTime; // returned
//theTime = new RTIfedTime( mxGetScalar(mscalar) );
//return theTime;
return ( (RTIfedTime)mxGetScalar(mscalar) );;
}
3 I run the demo controlFed_wTime and processFed_wTime and find they are all OK!
Can you tell me my modofication is correct?
|
Thu 05 Jun 2008 07:13:39 PM UTC, comment #15:
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
|
Thu 05 Jun 2008 07:07:09 PM UTC, comment #14:
Hi,
can you execute my attached matlab test?
I think all works fine but I have indeed problems
within the demo application in Matlab.
With the same apps in Fortran there are no probs.
I will fix your prob soon. But next week I've to visit
a fair. This takes the whole week. After that I fix the prob.
In the meantime can you tell me if you had problems to
execute my script?
(file #15799)
|
Thu 05 Jun 2008 12:43:31 PM UTC, comment #13:
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.
|
Thu 05 Jun 2008 07:59:01 AM UTC, comment #12:
Thank you I will try it.
|
Wed 04 Jun 2008 04:46:23 PM UTC, comment #11:
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?
|
Mon 02 Jun 2008 03:54:54 PM UTC, comment #10:
I see, now I understand what you've meant.
I'll will do some tests.
|
Mon 02 Jun 2008 03:27:39 PM UTC, comment #9:
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...
|
Mon 02 Jun 2008 02:58:16 PM UTC, comment #8:
I'm not sure if this bug is related to the zero-lh bug
because the demo (Matlab) use a lookahead of 0.1 (step
size of numerical integration), so it's not zero.
The C++ demo uses no time management functionality.
For Zheng:
I'm using Matlab7.1 too. The difference is, that I have a linux system here and that I compile the whole with gcc.
In the next two weeks I'm under heavy work load but after that
time I will find a solution for your prop. Probably I have to
set up a similar environment.
I think the billard example uses time mangement too.
Can you execute
billard -n test1 -f test -F Test.fed
and a second federate with e.g.
billard -n test2 -f test -F Test.fed?
|
Mon 02 Jun 2008 02:06:07 PM UTC, comment #7:
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?
|
Sun 01 Jun 2008 04:38:21 PM UTC, comment #6:
thank your reply. but I haven't resolve this problem.
I run the TwoLevelController demo (controlFed_woTime and processFed_woTime) without time management, it can run normally, but the demo with time management
(controlFed_wTime and processFed_wTime) does not work . some more information as follows:
1 My platform is windows XP professional with SP3, Matlab Version is 7.1, CERTI version is 3.2.7;
2 I used Camke 2.6 and visual C++.net 2003 to make a win32 project and compile CERTI ;
3 I compile the rti.cpp (MatlabHLA_Toolbox) with visual C++.net 2003 and build a dll (rti.dll),
but in order to build correctly on Windows XP platform, I change some include files,the head of rti.cpp is as follows:
#include "mex_vc.h"
#include <cstdio>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <memory.h>
#include <math.h>
#include <iostream>
#include <exception>
#include <winsock2.h>
//#include <arpa/inet.h>
//#include "mex.h"
#include "RTI.hh"
#include "NullFederateAmbassador.hh"
#include "fedtime.hh"
#ifndef _WIN32
#include <unistd.h>
#endif
the file 'mex_vc.h' is altered from "mex.h" ,it only change the row 'void mexFunction( ' into
'__declspec( dllexport ) void mexFunction( '
4 I try to run the C++ controller/process demo and find it runs OK on your config, TAR and TAG
are called in C++ demo, but TAG isn't called in MatlabHLA_Toolbox
|
Fri 30 May 2008 12:18:41 PM UTC, comment #5:
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.
|
Fri 30 May 2008 11:41:27 AM UTC, comment #4:
Hello Eric,
>>However the bug is interesing since I have another
>>user which exhibit just the same TAR with no TAG
>>behavior, but I'm not able to reproduce the bug... yet :=)
In what context appear this behaviour? Do you know
the sources?
TAR without TAG can be application specific (time
regulating <-> time constrained federates etc.)
|
Fri 30 May 2008 11:26:35 AM UTC, comment #3:
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?
|
Fri 30 May 2008 09:02:18 AM UTC, comment #2:
I'm not able to reproduce the problem with either
CERTI 3.2.7 nor CERTI cvs head.
But I've just realize your are using the MatlabHLA_Toolbox
and not the HLA_Tutorial app.
I re-assign the bug report to Christian
(the MatlabHLA_Toolbox author)
Nevertheless,
would you please give us more information:
0) What is your platform
System: Unix/Linux/Windows
Arch: Sparc, x86, x86_64 ...
Flavor: XP, 2000, Debian, Fedora...
Matlab Version
1) How did you compiled CERTI
cmake [the preferred way]
or
./configure
For Christian: I did check the C++ HLA_Tutorial
with both CERTI 3.2.7 and CERTI CVS and I did not
encounter any trouble.
However the bug is interesing since I have another
user which exhibit just the same TAR with no TAG
behavior, but I'm not able to reproduce the bug... yet :=)
|
Fri 30 May 2008 08:01:29 AM UTC, comment #1:
I'll investigate this right away.
|
Fri 30 May 2008 12:23:37 AM UTC, original submission:
When I trying to run TwoLevelController demo, I find the function timeAdvReq is not work, the timeAdvGrant function is not called,why?
|