VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Error with S-Function for NI Linux

Dear all,

 

I'd like to share with you an issue I’m facing trying to deploy an .so file to a PXI running NI Linux and compiled from a Simulink model which includes an S-Function.

 

In my company we have a quite complex C project developed in Visual Studio, which we have traditionally built as a static library (*.lib) for both Win32 and Win64 systems. We generate a S-Function for Simulink from this library using the Legacy Code tool from the Mathworks. Since several years, this has worked perfectly as we are able to use the library in simulation (Simulink), but also, we are able to build and deploy the S-Function to PXI systems generating a dll file for Pharlap using the Veristand Model Framework. This last using the Win32 version of the *.lib file built with Microsoft Visual C++ 2010 compiler.

 

So, everything goes well until now, when we want to use the same C Code in NI Linux 64 platforms.

 

Below the process we have followed:

  • Cross-compile the C code from Visual Studio using the “GNU C & C++ Compilers for x64 Linux” version 2017. So, we are able to generate a static Linux library (*.a file).
  • In order to check that the library is ok, we have generated an S-Function from it (using Legacy Code tool) but in a MATLAB which is running on Ubuntu.
  • Run the generated S-Function (*.mexa64 file) in a Simulink simulation. We have obtained the same simulation results (using the same Simulink model of course) in both MATLAB-Windows and MATLAB-Ubuntu. So, we are pretty sure that both libraries (*.lib and *.a) and both S-Functions (*.mewx64 and *.mexa64) are loadable and runnable in Windows and Linux based systems.
  • Next step has been returning to MATLAB-Windows and compile the S-Function using the Veristand Model Framework tool (target “NIVeriStand_Linux_64.tlc”). Apparently, everything goes well as the process ends correctly, the *.so file is generated and, even more, can be load in Veristand.

 

But the issue is that when I try to deploy it in the PXI running NI Linux. An error appears telling me that “The specified model is incompatible with NI Veristand…”.

 

So, my questions are:

 

Please find attached (in zip file):

  • A screenshot with the error I’m receiving when trying to deploy to the PXI
  • A txt file with the output coming from Simulink when compiling the S-Function
  • The *.so file I’m trying to deploy.

 

Thanks in advacned,

Borja

 

0 Kudos
Message 1 of 8
(2,062 Views)

Hello  Borja_85

I checked some error solutions and found something necessary links that can help you avoid this error. 

This forum post has solution for that error, check that and try to debug it again. 

 

Also there are 2 similar articles where described the solution of this error, go through these links you might find something necessary. 

1. Error -307703 The Specified Model is Incompatible with NI VeriStand - NI

2. Error -1 or Error -307703 When Adding vsmodel to VeriStand - NI

 

The next step I suggest to check is VeriStand compatibility with NI Linux Real-Time. I assume that you are using Linux RT version here, if it is not please let us know what NI Linux you are using and mention the version.

 

One of the possible reason can be migrating PharLap Application to NI Linux RT. I have attached the link where I suggest to double check if the migration was done properly. 

 

Regards )

0 Kudos
Message 2 of 8
(1,998 Views)

Hi I.hovs,

 

Many thanks for your feedback. I've checked the links you shared and here is my feedback.

 

I don't think that these links (This and 1. Error -307703 The Specified Model is Incompatible with NI VeriStand - NI) are applicable here as they ara based on using special characters in the model name. And I don't have any special character in the name.

 

Regarding this (Error -1 or Error -307703 When Adding vsmodel to VeriStand - NI), I had already checked that and tested it. Unfortunately with the same error.

 

Regarding this ( compatibility ), I'll check it. In the meantime, I'm using Veristand 2020 R6, RT Linux Image 20.x (I think), and 2017 version of the C/C++ cross compile tool. Any issue here?

 

About this ( migrating PharLap Application to NI Linux RT.), I'm not migrating an application from Pharlap. I have C static libraries for windows (*.lib) and Linux (*.a), which are working (tested under Windows and Ubuntu). These libraries are wrapped afterwards in a Simulink S-Function, which I'm compiling for NI Linux using Veristand Model Framework.

 

Best regards,

0 Kudos
Message 3 of 8
(1,974 Views)

Thanks for your feedback.

What I understand is that the VeriStand version witch you have mentioned is 20.x  inappropriate with NI Linux RT image version. See it from attached picture, witch I got from compatibility link. 

lhovs_1-1664546140360.png

So what I suggest you to update it into one of this versions on the pic. I think that might be the solution in this case since you already checked all the links I sent.

 

Let me know about any new updates and information.

Regards

0 Kudos
Message 4 of 8
(1,965 Views)

Hi,

Many thanks for your feedback. Sorry for the misunderstanding regarding the RT Image version, but the other day I didn't have the PXI and, therefore, I couldn’t check the RT version.


I can confirm that I’m using RT Image 21.5. So, according to the compatibility table, the so file should be loadable. Furthermore, I’ve created a virtual machine with NI Linux (following a couple of guides available in the web), I’ve installed also RT 21.5 on it but, unfortunately, I’m receiving the same error in both the PXI and the VM.

 

Plase find below a couple of screenshots showing the RT image installed on both PXI and VM (emulating an NI-cRIO)

 

Captura.JPG

Captura_2.JPG

 

Any other clue?

Many thanks,

0 Kudos
Message 5 of 8
(1,941 Views)

Dear all,

 

I have good and bad news from my side!

 

The good news is that I’ve been able to download the generated so file to the NI Linux RT. After deep investigation, I realized that some specific trigonometric functions were undefined in the generated so file.

I discovered this by executing “ld” command to the so file. The only thing I did is specify to the veristand.tlc file the “-lm” linker flag. After doing this, I’m able to download the so file to the PXI, but it is initially stopped.

If I do again “ld” to the so file, I’m receiving this:

 

Return of ld command for the so fileReturn of ld command for the so file

As shown, the only undefined symbols are functions that Versitand introduces in the so file when building from Simulink. I’m quite sure about this because I’ve generated an so file from a very simple Simulink example (just a sum of 2 inputs), execute the “ld” command and I get the same undefined symbols.

 

 

But here are the bad news…. When I tri to run the model from Veristand Channel Data Viewer, I’m getting a segmentation fault. Specifically, I’m receiving this message:

 

Segmentation FaultSegmentation Fault

 

Could you please give me some feedback about this? In the meantime, please find attached the generated so file (zipped) I’m trying to run.

 

Best regards

0 Kudos
Message 6 of 8
(1,900 Views)

Hi again,

 

Sorry, but I forgot to add an important detail. All static libraries I'm using are coss-compiled with the -fPIC flag.

 

Regards,

 

0 Kudos
Message 7 of 8
(1,896 Views)

Hi there, 

 

I’ve been working from my side on this and have good and bad news.

 

Good news is that I’m able to run the library in NI Linux. What I’ve done is create a Linux application in C from which I call the library (*.a) I'm using to generating the so file from Simulink. This runs properly.

 

However, bad news are that I’m not still able to run the so file generated from Simulink using exactly the same *.a library. So, I think that the issue might be related to the building process using the Veristand Linux tlc.

 

Does anyone know a way to debug step by step the so file execution in NI Linux from a Labview real time project for instance?

Is there any so file checker?

 

Best regards,

 

0 Kudos
Message 8 of 8
(1,846 Views)