Use embedded coder to write fast, efficient code for NI PXI and/or CRIO platforms

I'm trying to write a proposal for a piece of work, during which we may be required to port a large existing piece of Simulink code onto NI PXI and/or CRIO platforms. NI claim to have 2 methods -

http://www.ni.com/white-paper/7436/en/

- "LabVIEW Simulation Interface Toolkit" whose method is unclear to me, and seems to be very convoluted involving having MATLAB running the whole time, which I don't want - the software will end up running on the platform as embedded code, not on a PC.

or

- "LabVIEW Control Design and Simulation Module" which seems to be a Simulink-to-labview auto-translator (scary!)

I'm not convinced that either of these methods produce an end result which preserves the functionality or (importantly) speed of execution of a large simulink model in real time. My simulink model includes lower-level hand-coded S functions in C with associated tlc files, and complex hierarchical subsystems with mask initialization commands within some of the subsystems. I don't think any auto-translator will be able to effectively cope with these.

What I don't understand is why you can't just build the Simulink model using real-time workshop (and embedded coder) for an x86/PowerPC/ARM processor as appropriate for the NI device, and then port this C code direct into Labview so it executes efficiently. I don't see any references to this in LABVIEW/NI documentation and I do not understand why it isn't an advertised route. Is there some reason this won't work? I don't need the FPGA functionality on PXI or CRIO, just to have the Simulink code (auto-generated into C code) run just as efficiently as it does if I embed auto-generated C code from Simulink onto other processor targets (as we do on a number of non-NI targets using x86 and other processors).

I'n not very familiar with LABVIEW, but very familiar with Simulink.

Is NI gear and the labview interface particularly unfriendly to C code which is generated from Simulink using embedded coder? Does anyone have any experience of this? I guess you need to call the Initialiase() part of the auto-generated routine at the start, and then the mdl_step() function each frame, and the terminate() function at the end (if you can be bothered). Apart from that, shouldn't it be "simple" or at least do-able with low risk?

Why don't NI advertise this? Is is just a Labview vs MATLAB stand-off? Are there any MATLAB articles describing how to do this in steps?

If anyone can point me to a useful article, I'm open to any experience anyone has on the use of NI gear with Simulink.

Andrew

[Andrew Roscoe]

The following forum post concerning C code programming on the PXI is relevant. http://forums.ni.com/t5/PXI/Programming-PXI-Real-Time-Controller-in-C/td-p/935014

It also refers to the Labwindows/CVI programmer reference manual, which describes a 32-bit C compiler which can be used within Labwindows http://forums.ni.com/t5/PXI/Programming-PXI-Real-Time-Controller-in-C/td-p/935014

Perhaps I need to just find out if Embedded coder can write C code compatable with that compiler? I'm pretty sure PXI is x86-based so that should present no issues itself.

[Andrew Roscoe]

There is an NI manual "Using External Code in LabVIEW”

http://www.ni.com/pdf/manuals/370109a.pdf

It implies that inserting a "windows dll" into Labview is relatively easy (and, hopefully, efficient). Since mexw32 and mexw64 files are just dlls, could I generate a mexw32 file from a 32-bit MATLAB/Simulink installation (easy), and slot that into Labview, perhaps renaming it as a .dll, so it will execute on a PXI x86 target?

Does anyone have any experience of that?

If not, I know I can make x86-compatable code from Simulink, that's easy. The question then would be, how good is Labview at compiling that C code so it works efficiently on the target. This seems to me like it would be a really common desire with many users, but I don't find many references to it on the web!

[John]

Bump

I have exactly the same problem. Want to run Simulink control software on cRIO hardware

Apparently "LabVIEW Simulation Interface Toolkit" is now "LabVIEW Model Interface Toolkit". Reading the documentation, it seems Simulink generated dll will run standalone on the NI hardware. Not sure about efficiency or functional integrity though

I am still trying to figure out which target is appropriate for NI cRIO (NI Linux Real-Time maybe?)

http://zone.ni.com/reference/en-XX/help/374160B-01/vsmithelp/mit_model_support/

[Andrew Roscoe]

Thanks for keeping this going, John. Our particular project is just really starting off now, so we should be actually trying to do this, starting in the January timeframe - we need to lever our substantial Simulink/C code onto the PXI and CRIo chassis types, so some European partners can try out the algorithms.

The link you gave is quite useful. It suggests to me that to get the model into Labview to execute on a PC we should make the DLL (mexw64 I guess), but, if we actually want to run it on the PXI or CRIo then perhaps we need the ".so" format which I never encountered before.

There is a description of it here: http://uk.mathworks.com/products/embedded-coder/features.html?refresh=true

Shared Library Target — Generates a shared library version of your code for host platform execution, either as a Windows® dynamic link library (.dll) file or a UNIX® shared object (.so) file

Answer 1

[superaga]

Hi,

in 2018 (at least 4 years laters) I have the same problem.

While in the meantime, even "arduino" works for Simulink, a powerful target (like CRio) is still lacking this very complicated "feature".

Funny can't compile code for a computer...