Boost.Statechart and Simulink
I was wondering if there were any known issues with compiling using Matlab's mex compiler (which in turn uses and links with gcc) and using Boost.Statechart. When I implemented my statechart, I tested it using a separate main() file and it works 100%. When I compile using mex into a Matlab MEX file, I seem to lose the functionality of the event triggers. I've tried several things to figure out what is happening, but all I can ascertain is that if I use the iterators state_begin() and state_end() to access all internal states, the loop never executes. I tried to dereference state_begin(), but got a segfault. My initial approach was to use the state_downcast<>(), but this didn't work in SImulink either. My final suspicion was that it had something to do with the extern "C" business, but admittedly, I don't understand the effects of this statement other than how the symbol appears in the library (i.e. avoiding mangling). I get this same behavior on OS X 10.5 w/ gcc 4.0.1 as well as on Linux x86_64 with gcc 4.2.4. If anyone wants to have my Simulink model to test, I could send that as well. I've attached the following files: ctrl_machine.[ch]pp - My state machine implementation/declaration. main.cpp - My test program air_controller.cpp - The C++ SFunction implementation used in Simulink. mex uses the following compilation steps with gcc/g++ -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "ctrl_machine.cpp" -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "air_controller.cpp" -> gcc-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "/opt/matlab/extern/src/mexversion.c" -> g++-4.2 -O -pthread -shared -Wl,--version-script,/opt/matlab/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -o "ctrl_machine.mexa64" ctrl_machine.o air_controller.o mexversion.o -Wl,-rpath-link,/opt/matlab/bin/glnxa64 -L/opt/matlab/bin/glnxa64 -lmx -lmex -lmat -lm -lm ----- Thanks, Derek Ditch
Hi Derek
I was wondering if there were any known issues with compiling using Matlab's mex compiler (which in turn uses and links with gcc) and using Boost.Statechart.
No, unfortunately.
When I implemented my statechart, I tested it using a separate main() file and it works 100%. When I compile using mex into a Matlab MEX file, I seem to lose the functionality of the event triggers.
This seems to hint in the direction that the internal RTTI mechanism is failing. Have you tried to compile with BOOST_STATECHART_USE_NATIVE_RTTI defined in all translation units http://www.boost.org/doc/libs/1_37_0/libs/statechart/doc/configuration.html#...? Please let me know whether that changes anything. Thanks.
I've tried several things to figure out what is happening, but all I can ascertain is that if I use the iterators state_begin() and state_end() to access all internal states, the loop never executes.
This however does not fit with my RTTI mechanism failure theory. Even if it did fail, after calling initiate() the range [state_begin(), state_end()) should still not be empty. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
Hi Derek
I was wondering if there were any known issues with compiling using Matlab's mex compiler (which in turn uses and links with gcc) and using Boost.Statechart.
No, unfortunately.
Andreas, thanks for the reply. It turns out this was a bug in my code. I first got around this by creating a dynamic library and accessing the code that way. While it was a good lesson, it was a waste of my time and a hack. I read about this technique on another site, where the developers had some other issue with Matlab mangling their C++ when compiled under Visual C++.
I've tried several things to figure out what is happening, but all I can ascertain is that if I use the iterators state_begin() and state_end() to access all internal states, the loop never executes.
This however does not fit with my RTTI mechanism failure theory. Even if it did fail, after calling initiate() the range [state_begin(), state_end()) should still not be empty.
This turned out to be the problem. In my Matlab code, I failed to call initiate. Therefore, none of the state transitions could occur. I rewrote the code to call initiate and also to pass data through the events. Thanks again for your quick response. I'll check my code better in the future. -- Derek
participants (2)
-
Andreas Huber -
Derek Ditch