05-12-2019 05:23 AM
I'm replying as I have had much success with creating DLLs for LabVIEW pharlap targets using Matlab's coder. However I have never attempted to create a .so for a linux target. So my comments are speculative.
From a Matlab point of view, it is very capable of creating standard .c and .h files that can then be compiled to either dll or so files. And it sounds as if you are already creating dll files meaning that your matlab code is codable. You should thus be able to simply select a different target in Matlab (other than Win32 DLL) and it will generate the correct executable. It will probably ask you to point it to the appropriate compiler.
How then to call this shared library from LabVIEW? Do you also use the call shared library node as on a win32 platform, probably?
Any thoughts anyone?
05-12-2019 08:58 AM
Well your LabVIEW IDE is of course running on Windows and as long as you run your code on your development system the Windows DLL will work but your myRIO is a different computer (yes it is a real computer) which not only runs a different OS (NI Linux RT but also uses a different CPU (ARM instead of Intel x86).
Linux can't use Windows DLLs and even if it could, it's compiled for Intel x86 architecture which an ARM CPU can do nothing with.
When you put a VI into the myRIO target and deploy it to the target, LabVIEW cross compiles it automatically to run properly for the ARM CPU. When you put it into the My Computer target inside a project and run it, LabVIEW compiles it to run on your local x86 CPU.
Just as LabVIEW has not created your Matlab DLL, it can not create the correct Linux shared library for the myRIO to run. That is the task of the environment that created your Matlab DLL.
As I'm not familiar with Matlab, I can not give you a step by step explanation how to do it. Generally Matlab would somehow have to support the NI Linux target and also specifically the ARM variant of it (there are NI Linux targets which use the 64bit version of the Intel x86 CPUs).
If Matlab doesn't support that directly, which is very likely that it won't as Matlab and NI are known for not working together very well, you have to tell Matlab to somehow create ALL the c and h files for the project and then using the C cross compiler you can download from NI here (will require LabVIEW 2017 or newer) to compile these files into the shared library. However do not think that there is a trivial way to do that, there are several pitfalls with that:
- creating the Makefile for this is going to be a challenge unless you are a seasoned GCC programmer.
- Matlab would have to provide somehow the source code for all its own library functions too, in order to make this work. If they don't, they would have to provide a precompiled library file (*.o) or (*.a) specifically compiled with a compatible GCC compiler that can create ARMv7 eabi (soft fp) object code.
If any of the above sounds only like garbled chinese to you, then you would be better advised to hire someone with the necessary knowledge to do this for you if you really intend to make this work.
05-12-2019 10:34 AM
Well let's not put him completely off his mission. From a highly abstracted level, the job is simple:
1) Create a shared library (dll, so, something else) using Matlab, which targets the exact processor and operating system that the myRIO uses (see image below). Matlab also creates the .c and .h files if you would like to use another compiler. I may have skipped over some detail here but that discovery is part of the fun.
2) Copy the shared library in the file system of the myRIO.
3) In the calling vi, use Call Library Function Node to invoke a function in the shared library. Ensure you get all the function arguments and return values exactly to match what those in the .h file.
4) Deploy your calling vi to the myRIO and expect it to work first time.
5) Check what errors are raised and fix them one by one, becoming an expert debugger along the way.
6) Post back to this thread what eventually worked so it can help others.
Here is a screenshot of the Matlab Coder showing that it isn't too much work to target the myRIO's hardware configuration (I don't know the myRIO so I this may not be the exactly reflect it's hardware). There are several other settings that you can play with, e.g. choosing row-major or column major, and it may be required to do this to get this to work.
This is describing the happy-day scenario, be prepared for spend some time making this work.
05-12-2019 10:52 AM
Do you see where it says:
Device: AMD x86-64 (Linux 64)
If you can't make this read:
Device: ARM arm-eabi (Linux arm-eabi)
or something along these lines, then you won't be able to target the myRIO hardware.
The settings you show "MAY" (with a big may) work for the cRIO-903x series which use an Intel x86-64 CPU but not for the myRIO which uses a Xlinx Zinq chip with integrated ARMv7 core.
05-12-2019 11:37 AM
Yes if that exact target doesn't exist, then my two next options would be to:
1) Use the .c and .h files generated by the Matlab Coder and follow the method you mentioned above to compile this using the NI described process. From what you say this has quite a learning curve.
2) Purchase the Matlab Embedded Coder and Xilinx Zync Support from Embedded Coder and attempt to create the .so. I believe this also may have quite a learning curve and probably doesn't come cheaply.
3) Attempt to re-code the behaviour that is currently in matlab code into LabVIEW. This is probably the simplest option as I believe all Matlab functions that the Coder supports have equivalents in LabVIEW. This of course means you would have to revalidate the code by running it in LabVIEW on all the input data and comparing it with the outputs from the Matlab code. But at least you don't have to become an expert on cross-platform compiling and you wouldn't need to purchase expensive toolboxes.
4) Install matlab on the Zynq Linux and call Matlab directly from LabVIEW. Not sure if this is even possible but I heard you can install 3rd party software on the Linux operating system running LabVIEW RT?
Why I am interested in how this turns out is that we would eventually like to call code generated by the Matlab Coder on the cRIO (like the 9068).
05-12-2019 04:03 PM - edited 05-12-2019 04:09 PM
There are some comments/questions to the different points:
1) Does Matlab generate all the C code for cross compiling? If it only creates wrappers to call its standard library functions already precompiled then it won't work as you would need these precompiled libraries generated for the ARMv7 architecture.
2) This has some chance of working, although there are several variants of ABI (application binary interfaces) that can be used on ARM architectures and any precompiled libraries that come with these code extension need to match the ABI used on the NI Linux RT target.
3) This is definitely a viable solution although not a trivial one as there are definitly some differences in the mathematical libraries between Matlab and LabVIEW. Aside from things like scaling and not directly 1 to 1 compatible implementations, there is also the chance that the use of slightly different implementations in the arithmetic routines may cause different rounding errors which can make comparison of results more difficult.
4) Is there a Matlab version that can run on an Linux on an ARM CPU? I highly doubt that.
05-13-2019 12:27 AM
It seems we have given Sanju all the help we can. He will need to decide which route to follow and be open to putting in some effort as I doubt there is a simple 'video tutorial' as he is asking for. In reply to the 4 points:
1) Yes this is one of it's claims to fame, on the Matlab website: 'Run on Embedded Devices
Automatically convert MATLAB algorithms to C/C++, HDL, and CUDA code to run on your embedded processor or FPGA/ASIC.' The .c and .h files should be self-contained and standard C.
2) Sanju should contact his local Mathworks distributor and speak to the resident embedded application engineer for guidance on how to create a shared library for the Zynq 7010.
3) Yes the effort in this option is highly dependent on the complexity of the Matlab code, if he wrote the matlab code himself, this may be the most straightforward route.
4) Not sure, Sanju would have to ask Mathworks if a MCR (Matlab Compiler Runtime - this is required if you are NOT going to compile to c and h files and want to run the m file directly) is available for Linux running on an ARM processor.
05-13-2019 08:18 AM
thanks to all,
Actually i confused a lot and i'll try to follow all the steps given from your side. i dont no exactly matlab will generate all c and .h file for my program i'll check all.
09-14-2019 06:00 AM - edited 09-14-2019 06:07 AM
Hello,
I tried to convert the dll file from matlab working fine with labview but not with myrio so again i compile the file in linux platform and created .SO files but now am getting the error as mentioned below.
LabVIEW: Failed to load shared library En_Gen1.so:En_Gen:C . Ensure that the library is present on the RT target. Use either MAX to install NI software or FTP to transfer custom libraries to the RT target.
Here i attached the crested .SO file. Please do needful regarding this.
09-14-2019 07:19 AM - edited 09-14-2019 07:21 AM
In a Linux shell type "file <your so file>" and you will see something along the lines of:
En_Gen1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xd1abe5e65f768cb2b1332048ae3db180c7af0507, not stripped
Do you see the ELF 32-bit, Intel 80386 strings in there?
That means all these shared libraries were compiled to run on a 32-bit Linux installation that is running on an Intel x86 CPU.
Your myRIO has however an ARM CPU and needs a completely different version of the GCC compiler toolchain to generate a working .so file that can run on it. In one of my earlier posts I included a link to an installer for the correct compiler. You can either run this from the command line or instead install the Elipse based IDE that includes this compiler.
Once you successfully created your .so file with one of these solutions you have a chance to run the resulting .so on the myRIO. I say chance here because there are still many possible bears on the way to getting this really working.