I'm currently facing problems when integrating a OpenModelica FMU into my Simulink model. Everything works fine if I import the FMU as binary. Both FMU for co-simulation and model exchange can be imported and simulated (FMI 2.0). Unfortunately I have to run the Simulink model on a realtime platform and therefore I need to use the source code of the FMU and compile the s-function myself.

I managed to compile the s-function by tweaking the Compiler #defines like -DFMI2_FUNCTION_PREFIX=myModel_, -DOMC_FMI_RUNTIME=1, -DCMINPACK_NO_DLL=1. The MinGW compiler that is shipped with Matlab outputs several warnings:

Compiling S-function sfun_Testmodel

Building with 'MinGW64 Compiler (C)'.

In file included from D:\Modelica\Testmodel\sources\Testmodel_FMU.c:55:0:

D:\Modelica\Testmodel\sources\fmi-export/fmu2_model_interface.c.inc: In function 'omc_assert_fmi_common':

D:\Modelica\Testmodel\sources\fmi-export/fmu2_model_interface.c.inc:169:16: warning: passing argument 1 of 'GC_vasprintf' from incompatible pointer type [-Wincompatible-pointer-types]

   GC_vasprintf(&str, msg, args);

                ^

In file included from D:\Modelica\Testmodel\sources\openmodelica_func.h:52:0,

                 from D:\Modelica\Testmodel\sources\Testmodel_FMU.c:10:

D:\Modelica\Testmodel\sources\util/modelica_string.h:71:5: note: expected 'const char **' but argument is of type 'char **'

 int GC_vasprintf(const char **strp, const char *fmt, va_list ap);

     ^

In file included from D:\Modelica\Testmodel\sources\Testmodel_FMU.c:56:0:

D:\Modelica\Testmodel\sources\fmi-export/fmu_read_flags.c.inc: In function 'FMI2CS_initializeSolverData':

D:\Modelica\Testmodel\sources\fmi-export/fmu_read_flags.c.inc:181:7: warning: implicit declaration of function 'access' [-Wimplicit-function-declaration]

   if( access( flags_filename, 0 ) != -1 )

       ^



D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c: In function 'ModelicaError':

D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c:83:1: warning: 'noreturn' function does return

 }

 ^

D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c: In function 'ModelicaVFormatError':

D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c:87:1: warning: 'noreturn' function does return

 }

 ^

D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c: In function 'ModelicaFormatError':

D:\Modelica\Testmodel\sources\util\ModelicaUtilities.c:94:1: warning: 'noreturn' function does return

 }

 ^



D:\Modelica\Testmodel\sources\simulation\solver\initialization\initialization.c:77:12: warning: 'init_lambda_steps' initialized and declared 'extern'

 extern int init_lambda_steps = 3;

            ^



MEX completed successfully.

When I start the model Matlab crashes without any signs.
I experience the same with Microsoft Visual C++ 2017 compiler. To get this compiler working I had to install the pthreads-win32 package and substitute strncasecmp() with the equivalent Windows implementation. Doing this I don't get any compiler warnings but Matlab crashes during model initialisation. Unlike MinGW there is the possibility to send a crash report with a stack trace.

Is this a bug with the exported source files? I thought that the source files inside the FMU should be able to be compiled without any dependencies (OMC Pull request 2989).  I'm using OpenModelica 1.18.0 with FMIKit Simulink 2.9 and Matlab 2018a.

Hello Giuseppe,

I just made some tests with the Modelon FMI Toolbox to do model exchange (not Co-Simulation). Because of the unavailability of a 64-bit Version of OpenModelica at that time I used Dymola with the Dymola block in Simulink. My tests with the 32-bit Version were successful. First there were some problems with DLL dependencies (that's why I created this thread) but they are fixed now. Since Matlab 2015a you can use a so called Pilot Support Package from Mathworks to use FMUs in Simulink. You have to ask the Mathworks support for the download link. This package also worked in my tests.

Best regards,
Andreas

Hello Adrian,

the FMU Export works for the latest nightly build (v1.9.4-dev-337-g300f04e) with OMEdit. Your effort in reducing the dependencies for the generated FMU is very useful when including the generated FMU on realtime platforms like dSpace. Is this also one step towards support of 64bit Windows FMU target?

Unfortunately I can't get to work your solution for generating FMUs via the scripting engine. There are only few file generated (FMUTest.libs, FMUTest_FMU.libs, FMUTest_FMU.log, FMUTest_FMU.makefile, FMUTest_info.json). Some of them are empty.

Best regards,
Andreas

I just changed libgfortran-3.dll in the subfolders /bin and /MinGW/bin with the version dchneric supposed and FMU export works out of teh box now.

Hello dchneric,

thank you for your answer. This solved my problem. The import of the generated FMU in Simulink works. Is this a known problem and is this fixed in newer builds of OpenModelica? I'm currently using OpenModelica v1.9.4-dev-111-g56804f2.

Is there a way to exchange the libgfortran-3.dll to make this workaround a permanent solution to the problem?

Best regards
Andreas

I got the same behavior with Matlab 2013b and FMI Toolbox from Modelon as well as Matlab 2015a an the Pilot Support Package from Mathworks (the planned native FMI support from Simulink). Both were the 32-bit versions. That would lead to the next question about the 64-bit support for the windows. But this is perhaps better done in a separate thread.

The error occurs when I start the simulation. Importing the FMU is no problem. I have not tested importing my FMU into Dymola. I hope I can get a copy in the next days. Maybe there is a similar problem as you mention in the Makefile that Dymola is not yet supported.

Hello Adrian,

thank you for the quick reply. I just tried out the latest nightly build. Now the Export seems to work. At least the FMUChecker doesn't throw any errors. Unfortunately the import into Simulink doesn't work. Now the toolbox gets the error of "forbidden access to memory area". Maybe a have to search for the next link in the chain...

Best regards
Andreas

I found some hints in the ChangeLog for Release 1.9.3:

* commit 38887f3d8797613c8a7dd6d096f8124597182d4a
| Author: hudson <openmodelica@ida.liu.se>
| Date:   Mon Jun 29 15:44:34 2015 +0200
|
|     * OMCompiler 48def8b...e234aa1 (4):
|       > Fixed FMU2-Errors. Static member FMU2Wrapper::logCategory is now FMU2Wrapper::LogCategoryFMU
|       > Logger for CPP-Runtime updated
|       > - added boost::atomic to windows cpp-runtime-build
|       > - replaced boost_log with logger-class of cpp-runtime - moved the implementation of StaticNonLinSolver-, StaticLinSolver- and StaticSolverOMCFactory to code files (because otherwise we are not able to disable cvode and kinsol for FMU export, easily) - FMU is now using Newton instead of Kinsol by default - FMU has no dependencies to sundials anymore

Later posts in the Changelog give the hint that there are some switches that can be passed to the FMU generation process:

* commit 78fbad2b7b5b97a97717ee4ce6a7551f914123aa
| Author: Marcus Walther <marcus.walther@tu-dresden.de>
| Date:   Mon Jul 27 14:14:23 2015 +0200
|
|     * OMCompiler 810476f...d9b26e6 (1):
|       > - Kinsol can now be used for FMUs, by passing a parameter to cmake - added some logger output to the kinsol and newton solver


Can anyone please give me advice where to pass the parameters to the generation process.

Hi.

I'm trying to export my Modelica models into an FMU (for Model Exchange) to integrate it into Simulink (with FMI Toolbox from Modelon). I get the error that the DLL could not be loaded. With the help of the FMUChecker (from https://www.fmi-standard.org/) I found out that it is not the Model-DLL that cannot be loaded but the Libraries of the Sundials package (libsundials_kinsol.dll and libsundials_nvecserial.dll)

My question is now whether the functions could be compiled into the FMU DLL rather than just linked dynamically. Is there a hidden switch where I can do that? Or is that the only way things can be done? If you always need certain special libraries in order to import OpenModelica generated FMUs I think this functionality is useless.

Best regards
Andreas