Building a .so model from Simulink

[semarcorra]

Hello everyone, 

My purpose is to build a Simulink model of a wind turbine in order to perform a HIL simulation in VeriStand 2020. 

I am currently able to build small Simulink models into .so files that run correctly in VS. But when it comes to the proper wind turbine model (which is big and complicated), the following error occurs:

=== Build (Elapsed: 4:40 min) ===
### Starting build procedure for model: SM_Offshore_Windturbine
### Generating code and artifacts to 'Model specific' folder structure
### Generating code into build folder: C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw
Warning:Matching "Goto" for "From" 'SM_Offshore_Windturbine/SCOPES/From15' not found
### Invoking Target Language Compiler on SM_Offshore_Windturbine.rtw
### Using System Target File: C:\Program Files\MATLAB\R2019a\rtw\c\grt\grt.tlc
### Loading TLC function libraries
### Initial pass through model to cache user defined code
### Caching model source code
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
......................................
### Writing header file SM_Offshore_Windturbine_types.h
### Writing source file SM_Offshore_Windturbine.c
### Writing header file SM_Offshore_Windturbine_private.h
### Writing header file SM_Offshore_Windturbine.h
### Writing header file rtwtypes.h
### Writing header file builtin_typeid_types.h
.
### Writing header file multiword_types.h
### Writing header file rtGetInf.h
### Writing source file rtGetInf.c
### Writing header file rtGetNaN.h
### Writing source file rtGetNaN.c
### Writing header file rt_nonfinite.h
### Writing source file rt_nonfinite.c
.
### Writing header file rtmodel.h
### Writing source file SM_Offshore_Windturbine_data.c
### TLC code generation complete.
### Using toolchain: MinGW64 | gmake (64-bit Windows)
### Creating 'C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw\SM_Offshore_Windturbine.mk' ...
### Building 'SM_Offshore_Windturbine': "C:\PROGRA~1\MATLAB\R2019a\bin\win64\gmake" -f SM_Offshore_Windturbine.mk all
.........
C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw>cd .

C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw>if "" == "" ("C:\PROGRA~1\MATLAB\R2019a\bin\win64\gmake" -f SM_Offshore_Windturbine.mk all ) else ("C:\PROGRA~1\MATLAB\R2019a\bin\win64\gmake" -f SM_Offshore_Windturbine.mk )
"C:\PROGRA~3\MATLAB\SupportPackages\R2019a\3P.instrset\mingw_w64.instrset\bin/gcc" -c -std=c99 -pedantic -fwrapv -m64 -O0 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DMAT_FILE=1 -DONESTEPFCN=1 -DTERMFCN=1 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DNI_ROOTMODEL_SM_Offshore_Windturbine -DTID01EQ=1 -DMODEL=SM_Offshore_Windturbine -DNUMST=2 -DNCSTATES=96 -DHAVESTDIO -DRT -DUSE_RTMODEL @SM_Offshore_Windturbine_comp.rsp -o "rt_logging.obj" "C:/PROGRA~1/MATLAB/R2019a/rtw/c/src/rt_logging.c"
"C:\PROGRA~3\MATLAB\SupportPackages\R2019a\3P.instrset\mingw_w64.instrset\bin/gcc" -c -std=c99 -pedantic -fwrapv -m64 -O0 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DMAT_FILE=1 -DONESTEPFCN=1 -DTERMFCN=1 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DNI_ROOTMODEL_SM_Offshore_Windturbine -DTID01EQ=1 -DMODEL=SM_Offshore_Windturbine -DNUMST=2 -DNCSTATES=96 -DHAVESTDIO -DRT -DUSE_RTMODEL @SM_Offshore_Windturbine_comp.rsp -o "SM_Offshore_Windturbine.obj" "SM_Offshore_Windturbine.c"
"C:\PROGRA~3\MATLAB\SupportPackages\R2019a\3P.instrset\mingw_w64.instrset\bin/gcc" -c -std=c99 -pedantic -fwrapv -m64 -O0 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DMAT_FILE=1 -DONESTEPFCN=1 -DTERMFCN=1 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DNI_ROOTMODEL_SM_Offshore_Windturbine -DTID01EQ=1 -DMODEL=SM_Offshore_Windturbine -DNUMST=2 -DNCSTATES=96 -DHAVESTDIO -DRT -DUSE_RTMODEL @SM_Offshore_Windturbine_comp.rsp -o "SM_Offshore_Windturbine_data.obj" "SM_Offshore_Windturbine_data.c"
Error:SM_Offshore_Windturbine_data.c:1895992:3: internal compiler error: Segmentation fault
{ 0.0, 0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.55, 0.6, 0.65,
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://sourceforge.net/projects/mingw-w64> for instructions.
gmake: *** [SM_Offshore_Windturbine_data.obj] Error 1
C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw>echo The make command returned an error of 2
The make command returned an error of 2
C:\Users\piova\Desktop\Modello_Wind\Modello_Eolico_Offshore_6DOF-20201103T162424Z-001\Modello_Eolico_Offshore_6DOF\08 - Results\SM_Offshore_Windturbine_grt_rtw>exit 1
### Build procedure for model: 'SM_Offshore_Windturbine' aborted due to an error.
Error:Error(s) encountered while building "SM_Offshore_Windturbine":
### Failed to generate all binary outputs.
 

I contacted the MathWorks support, and they told me that most likely the problem is due to the complexity of my model, and that if I cannot reduce its dimensions (and this is my scenario), then the only thing that can possibly be done is looking for a "more efficient compiler" (quote). 

I am using the C/C++ development tools, but I think that this is actually the only option for the compiler. Am I right? 

I do not know how to proceed, any help would be appreciated. 

Thanks, 

- Marco S.

[Pog2k]

The C file you are trying to compile seems to be very long.

What you can try:

• check if you don't run out of RAM during compiling.
• Split your Model and try to compile portions of it.
  • Tell Simulink to compile into multiple C files.
  • Or create independent Subsystems and load multiple models into veristand.
• Try a different compiler. Newer GCC or Clang. <- But I would rather check the options above (:

[ecleary42]

---

### Failed to generate all binary outputs.

so whats the deal with your binary outputs?  are you using arrays or clusters?  you should isolate your binary outputs and see if you can compile a model with them as they are in your original model 

[semarcorra]

Hello there, thanks for your replys.

@Pog2k, I tried splitting the model already and indeed with small subsystems the compilation runs correctly. By the way, the needed number of subsystems that VeriStand will need to manage is therefore very high and it becomes a complex task. Now I am trying to simplify the model as much as possible, but I do not have much freedom in this sense. 

You said that in fact I could try with different compilers, but I searched on the web and I could not find explicit information about whether GCC and/or Clang are supported with VeriStand. But I am not expert in compiling, do you have any advice regarding this? 

Thanks in advance, 

- Marco S.

[semarcorra]

@ecleary42 thank you for your answer. As I said before I am not expert at all in compiling and I did not understand your point. What do you mean with isolating the binary outputs and with " compile a model with them as they are in your original model"?

I would really appreciate if you could explain this explicitly for a dummy like me 🙂

[Pog2k]

Your problem is this:

Error:SM_Offshore_Windturbine_data.c:1895992:3: internal compiler error: Segmentation fault

So simulink created a big C file and the GCC crashes at line 1895992.

This "Segmentation fault " could caused by many reasons, but which could be obvius is that the compiler has to struggle which such a big file. Maybe you are running out of ram, which could be easily check if you look into your task manager during compilation.

If you google the error someone else had the same problem and solved it by updating the gcc compiler. But if you run out of ram the compiler update will also not be succesfull either.

https://stackoverflow.com/questions/44286265/g-internal-compiler-error-segmentation-fault-program-cc...

If you are not familar whith compiling, makefile etc. you shouldn't try it, because you have to make changes into the existing matlab build tool chain which can be very time consuming.

Instead of compiling one big clumsy C file, you could force simulink to split up the code into multiple smaller c files.

This would then be easier for the GCC Compiler and you don't have to split your subsystems into different veristand models.

In the end multiple c files are then compiled into object files and will be then linked into your shared object. So you will have one model again

https://de.mathworks.com/matlabcentral/answers/93591-can-i-separate-or-split-large-generated-files-i...

[semarcorra]

Hello, 

I finally managedd to build a .so file from the Simulink model (basically, the problem of the compilation was the presence of some huge look-up tables; I reduced their dimensions and then the compiler was able to manage the task).

By the way, I am now facing another problem. My aim at the moment is to analyze the behavior of the .so model in VeriStand and to compare it to the one in Simulink. To do so, I created a stimulus profile with an associated real time sequence imported (and formatted) from Simulink.  Practically, I am running the same simulation in the two different environments and I expect the outputs to be comparable.

In fact, the outputs of the .so model in VS diverges in a few seconds (I visualized it with a graph on VS workspace), and eventually they become Nan, whereas what I see in Simulink is a certain graph over time that is finite and well-defined. 

I am sure that no mistakes have been made during the importing of the .csv file (I am able to display the inputs in a graph and they are consistent with those I see in Simulink), moreover I noticed that the same behavior occurs also when the inputs are all null.

Is it possible that the compilation is actually not able to "translate" correctly some of the Simulink blocks, thus resulting in a computational error of the deployed model, while the compiler does not recognize that something has gone wrong?

Does anyone have any hint about this weird behavior?

Thanks everyone, 

- Marco S.

[ecleary42]

Hi semacorra,

well done on working out your original issue!

My original point is null because you fixed your issue but I'll briefly explain what I was getting at, the original error message you got stated that it failed to generate all binary outputs, so by asking you to isolate these outputs and compile a model I was trying to discern if these were the cause of the compliation error because if your binary outputs was causing an error in compiling one model then they would cause an error in compiling a simple model with the same outputs.  Just an attempt of narrowing down the issue

I have used simulink models in VeriStand (10 year old code done by someone else 🤢), I am a LabView developer but I can at least read Simulink as I did a bit in college.  This model uses a state flow machine and many different types of simulink function blocks.  This compiles and runs in VeriStand without issue, its a rather complex and large model so I cant see the contents of your model being an issue, however this isnt to say that its not

Ensure your version compatibility is correct: https://www.ni.com/en-ie/support/documentation/compatibility/17/veristand-version-compatibility.html

In this link: https://zone.ni.com/reference/en-XX/help/372846M-01/veristand/model_support/

about SimuLink model comatibility it states:

Simulink Model Compatibility

In the Simulink software, you can convert models that use only a fixed step-size ordinary differential equation (ODE) solver into compiled models. Additionally, you must turn off data logging in the Simulink application software. Refer to the Simulink documentation for information about using the Simulink application software to change the ODE solver of a model and turn off data logging.

So make sure your model design does not go against this

Read this article and ensure your model complies with it https://zone.ni.com/reference/en-XX/help/372846M-01/veristand/models_mdl_in_vs/

Another question to ask yourself is are you using the Simulink Coder software to compile your model and if so have you chosen the correct target type when compiling?  https://zone.ni.com/reference/en-XX/help/372846M-01/veristand/convert_model_to_dll/

After all that if you conclude your model is fine (and it should be) then it is most likely down to your sequencer code, you are probably sending zeros to your inputs and if for example if you divide a value by zero this will give you a NaN output, any function therafter that recieves NaN at its inputs will output NaN also. 

I have found the VeriStand sequencer to be a real pain to get working in the way that I expected it too and have found that I would need to spend a lot of time debugging to get it to work correctly, even for simple tasks.  So much so that I have taken to writing sequencers as inline sychronous cutsom devices in LabView, they are much easier to code and debug in the long run, so if you can code in LabView then I would suggest doing this otherwise I would work with the VeriStand sequencer application to create and run your sequences and log all inputs and outputs whilst doing so to give yourself a more intuitive way to debug your sequence code

Hope something here helps 🙂