NI Linux RT on Desktop PC

[JimPanse]

Hi Experts,
there is a guide, experience or an image with which you can configure a desktop PC to a Linux NI RT?
a pleasant week, Jim

[Rolf Kalbermatter]

31 minutes ago, JimPanse said:

Hi Experts,
there is a guide, experience or an image with which you can configure a desktop PC to a Linux NI RT?
a pleasant week, Jim

I haven't really looked into this and I'm not aware of such a specific guide. My guess is you have to setup a linux cross compile setup on your PC, then download the NI Linux RT source code and go through the configuration settings of the linux compilation, selecting everything that would make sense for your (virtual) target hardware. That gives you in the end a hopefully working Linux RT kernel that is compatible to NI Linux RT.  

Now, NI Linux RT is of course a nice thing but completely useless as a target for LabVIEW RT without also the LabVIEW runtime engine, NI-VISA, NI-DAQmx, NI-half a hundred other software libraries and drivers. And here you start to bite in the dust. You can't just recreate them for your target system and you are not allowed to copy them over from another LabVIEW RT system without expressed consent from NI and in the case of the LabVIEW runtime engine an actual license payment too!

[JimPanse]

Hello Rolf,

thanks for the expanded view. If I configure a desktop PC with a Pharlab Labview RT system I need the appropriate license. NI also has to pay for this eventually. These costs should not be incurred in Linux. Licensing costs for example, DAQ should not apply also. These costs should be compared with the hardware procurement. Therefore, some applications would be implemented with a desktop Linux NI RT system. Or did I miss something?

A pleasant start to the week, Jim

[Rolf Kalbermatter]

It's not that easy. You do not pay for a runtime license of the Linux kernel. That is open source and NI provides all the sources to recreate it, if you wish. But NI Linux RT while a full OS is simply that! No LabVIEW runtime, NI-VISA runtime, NI-488.2 runtime, NI-DAQmx runtime, NI-RIO, NI-this and NI-that. And for these things, and especially the LabVIEW runtime, NI is free to define whatever license conditions they like and they decided that running these on non-NI hardware generally will require a paid license from them.

You are free to build your own NI Linux RT OS for whatever hardware you like, but you are not free to put any of the NI software  even in runtime form on it without a license from NI. And no, just because you can redistribute a LabVIEW executable including the LabVIEW runtime on a desktop system without additional runtime licenses does not mean that you have the right to grab a LabVIEW runtime from an NI Linux embedded target and copy it to your own hardware , even if it would be technically possible, which for most targets is not easily possible even if they use the same CPU architecture.

NI Pharlap isn't that different really. They probably have a royality free source code license from Pharlap for this (which would cost A LOT of money, which of course has to be incurred somehow and probably comes with a similar expensive yearly maintenance contract for them). The license cost for the NI Pharlap system on your own hardware is for the most part the same as for the NI Linux software. It's for the LabVIEW runtime and all the other necessary software drivers, not so much for the Pharlap OS.

NI makes quite a bit of money with their realtime platforms and they want to protect that somehow. And being the copyright owner of all the NI developed software drivers and LabVIEW, they have every right to do so in pretty much every way they find ok. That you and me would rather have it different isn't really a valid argument against that.

Edited June 20, 2016 by rolfk

[smithd]

Its also possible to start with one of the normal desktop linux targets NI nominally supports and pull in the various rt kernel patches yourself (Preempt_rt is mentioned here for example: http://www.ni.com/white-paper/14627/en/). However it sounds like this isn't going to help you as you still lose the ability to do RT in labview: https://decibel.ni.com/content/message/61652 (ie you'd have access to RT capabilities in C but not labview).

 

I am curious why the available pharlap solutions arent any good? I've had the same issue recently but thats just because I have a bunch of computers available to me that all have the wrong NIC for pharlap.

Edited June 21, 2016 by smithd

[Rolf Kalbermatter]

I can't speak for others, but for me the NI Linux RT virtualized hardware system would be mostly for testing and debugging LabVIEW software on one of the x86 based cRIO targets without having to always be connected to the actual hardware target. Yes it doesn't allow for full hardware access such as DAQmx, RIO etc. but it would allow some easy testing of the general RT application and in my case especially shared libraries on these platforms.

[ShaunR]

1 hour ago, rolfk said:

I can't speak for others, but for me the NI Linux RT virtualized hardware system would be mostly for testing and debugging LabVIEW software on one of the x86 based cRIO targets without having to always be connected to the actual hardware target. Yes it doesn't allow for full hardware access such as DAQmx, RIO etc. but it would allow some easy testing of the general RT application and in my case especially shared libraries on these platforms.

You speak for me too.

Generally there are only two things that prevent me supporting all LabVIEW platforms for my products:

• Hardware to test on
• NI Third Party Licensing Toolkit.

For the SQLite API for LabVIEW the second one is moot so it is only a test platform that prevents me supporting Linux RT, PXI and x86 cRIO.

[Rolf Kalbermatter]

On 21-6-2016 at 4:34 PM, ShaunR said:

For the SQLite API for LabVIEW the second one is moot so it is only a test platform that prevents me supporting Linux RT, PXI and x86 cRIO.

The issue is a little more complicated actually since NI Linux RT isn't a single platform but really two (x64 and ARM).

There is no easy solution to provide a virtualized environment for testing on the ARM platform (but with the myRIO you do have a fairly accessible platform for testing).

So far we have these variations of platforms for LabVIEW RT:

x86                            Pharlap ETS

PPC                           vxWorks 6.1 (LV 8.2.1) and vxWorks 6.3 (>= LV 8.5)

ARM                          NI-Linux RT

x64                            NI-Linux RT

For all but the Pharlap ETS system virtual machines for testing are only theoretically feasable for the NI-Linux RT for x64 platform. All the others already fail because of a very different CPU architecture and adding Bochs or something similar to the virtualization effort is definitely creating an even bigger problem. Still remains the issue that without an NI sanctioned way of creating an NI-Linux RT (x64) image, it's not only legally but also technically pretty impossible to create a fully functional LabVIEW RT target for virtual machine execution. There are simply to many runtime libraries that need to be copied to the right locations, that are not part of NI Linux RT itself but additional components with specific NI license restrictions.

There are also possibilities for some of the x86/x64 systems to run Windows Embedded but for testing purposes of libraries they are really the same as a standard Windows systems if you don't access very obscure features.

Edited June 29, 2016 by rolfk

[ShaunR]

2 hours ago, rolfk said:

The issue is a little more complicated actually since NI Linux RT isn't a single platform but really two (x64 and ARM).

There is no easy solution to provide a virtualized environment for testing on the ARM platform (but with the myRIO you do have a fairly accessible platform for testing).

So far we have these variations of platforms for LabVIEW RT:

x86                            Pharlap ETS

PPC                           vxWorks 6.1 (LV 8.2.1) and vxWorks 6.3 (>= LV 8.5)

ARM                          NI-Linux RT

x64                            NI-Linux RT

For all but the Pharlap ETS system virtual machines for testing are only theoretically feasable for the NI-Linux RT for x64 platform. All the others already fail because of a very different CPU architecture and adding Bochs or something similar to the virtualization effort is definitely creating an even bigger problem. Still remains the issue that without an NI sanctioned way of creating an NI-Linux RT (x64) image, it's not only legally but also technically pretty impossible to create a fully functional LabVIEW RT target for virtual machine execution. There are simply to many runtime libraries that need to be copied to the right locations, that are not part of NI Linux RT itself but additional components with specific NI license restrictions.

There are also possibilities for some of the x86/x64 systems to run Windows Embedded but for testing purposes of libraries they are really the same as a standard Windows systems if you don't access very obscure features.

Like I said, the only thing preventing me is the *hardware* to test on. Software is not really a barrier for me or the platform "type" because I'm not particularly clever, but I am persistent   I pretty much have a one click (well, 3 click) process for producing the binaries for all the platforms (except VxWorks) now so the overhead of creating them has been solved. No-one is asking for these platforms so it is really my own satisfaction in striving for completeness.

Virtual machines would be better if, and only if, there isn't a cost associated and they accurately reflect the hardware target. Because the API is free, there isn't a lot of incentive go out and spend real money on expensive NI hardware on the offchance that someone *might* use it. The only realistic way new platforms will be added (if no VMs are available) is through sponsorship or someone donates a device. I did go out and buy a VxWorks (6.3) RIO - quite a while ago now - because that only left the PXI racks (Pharlap ETS) at the time but obviously more platforms have been released since then.

My own self satisfaction isn't enough for me to spend more of my own money on hardware just for testing once or twice a year when the burden of maintaining the binaries is not trivial and no-one really wants them.

Just to be clear, though. This is a mainly a support issue. The API probably does work on those platforms with the standard SQLite binaries but even then I cannot support those platforms without test targets.

Edited June 29, 2016 by ShaunR