What boards other than cRIO can run LabVIEW RealTime?

[JHugh]

I'm a bit confused as to why it would be illegal? I have already purchased LabVIEW and LabVIEW RT from NI, and I just want to install it for use on a SB that is not a cRIO. This link: http://sine.ni.com/nips/cds/view/p/lang/en/nid/13751 seems to say that it is possible and legal.

I was just looking for information on whether anyone had any good or general recommendations of a SB or microcontroller that would have the features that I needed.

[rolfk]

That is the LabVIEW Realtime ETS system. A runtime license for the Pharlap ETS system to install on x86 compatible systems with certain specific hardware requirements for this to work. Nothing similar exists for the new NI Linux Realtime systems.

You can install the LabVIEW Realtime ETS system also on embedded controller boards if they provide the hardware resources the Pharlap ETS system requires. Besides that it needs to be an x86 based PC compatible system it also needs to have specific network controllers for it to work. It won't be Linux though but Pharlap ETS, a realtime system at about the software state of Windows NT4.0.

NI never released a similar runtime license for their followup realtime hardware systems based on VxWorks (for their PPC based hardware boards) or the NI Linux Realtime systems (for x64 and ARM controllers) and I doubt they feel very compelled to do so.

If you don't want to run any LabVIEW application on the target, then there are really a myriad of possible controller boards that could be used and selecting one of them based on specific requirements is maybe troublesome, but due to the fast moving state of this market it is not very likely that a solution that someone chose a year ago which might miraculously have exactly your requirements is still a good choice or even available for purchase now.

[rolfk]

And before you ask, NI couldn't and doesn't restrict you to install your own self compiled version of the Linux kernel used in NI Linux Realtime, but you have no legal right to run the NI LabVIEW realtime runtime system, and all the various NI-VISA, NI-DAQmx, NI-IMAQdx, etc. etc. software components on any hardware without a valid license from NI. The NI controllers come with this license included, non NI controllers do not have such a license.

Linx 3.0 comes with a license to use some of these components for non-commercial applications on the Raspi and Beaglebone Black, but that's it.

[JHugh]

So, if I understand correctly, if we decide to use Pharlap ETS Realtime on our own microcontroller, we should still have access to all of NI's libraries (NI VISA, NI DAQ, NI Realtime, general blocksets like the IPv4 blockset etc.)? We would only not have access to whatever Linux libraries were on the cRIO and instead have Pharlap ETS libraries?

[rolfk]

That is about right. Basically the API supported in Pharlap ETS is similar to what Windows NT 4.0 and to some extend Windows XP did provide, except a number of features that make not much sense on a realtime system (user management and extended access right management) or were hard to implement back then (Unicode support) or simply to cumbersome (anything ActiveX or .Net based). The high level API is Win32 compatible including having to access a Winsock like interface if you want to do network communication from your own C coded shared library. I'm not sure if that Winsock implementation does support IPv6 though.

One of the reasons NI stepped away from the Pharlap OS for their realtime controllers is that it is basically a legacy system that is hard to add support for nowadays standard features and impossible to port to other hardware architectures than x86.

[Bob_Schor]

Rolf,

     I knew that NI was using Linux on some of their controllers, so I made the (apparently-incorrect) "leap" that if Linux runs on PCs, LabVIEW RT runs on Linux, and LabVIEW RT can run on PCs, that NI had a "Linux" (in addition to PharLap) version of LabVIEW RT for the PC.  Thanks for clarifying -- I wonder when/if such an advance will be forthcoming ...

Bob Schor

P.S. -- don't some Intel-chip controllers for the PXI come with Linux options?  Thought I remembered hearing about this at NIWeek a few years back, maybe I was confused with a RIO product ...

[Hooovahh]

Yes I too wish there was a Linux RT option for industrial computers.  I can understand maybe why NI doesn't have this as an option yet.  NI has a similar stance when it comes to Linux RT in a virtual machine.  Near the end of that thread there was a solution on putting the Linux RT OS in a VM and I assume one could make that work on an actual computer too, but support would be non-existent from NI, and it may break several EULA's of NI's.  Best bet might be Pi for non commercial, and if you are looking for budget, the myRIO for anything else.  They are marketed toward students but there is a non-academic option.

[natasftw]

Bob,

All of the current PXI controllers run Phar Laps.  https://www.ni.com/en/support/documentation/compatibility/17/real-time-controllers-and-real-time-ope...

JH,

The real-time deployment license linked is the Phar Laps license we discussed prior.  It doesn't include Linux.  In order to use Linux, you'd need to have some form of agreement.  The only way to run LVRT applications would be with the LVRT Runtime Engine.  Installing that without a license for it would push your legal boundaries, at best.  That's where the advice is coming from.

But, that still doesn't answer the question.  WHAT is driving this limitation?  "The customer isn't ok with NI hardware" isn't an answer.  They have a reason.  What is it?  If you're wanting to use LVRT, the reason may not be valid.  If it is valid, LVRT may not be your solution.  From what you've given us, you're trying to force square pegs into triangle holes. 

[JHugh]

---

natasftw wrote:

But, that still doesn't answer the question.  WHAT is driving this limitation?  "The customer isn't ok with NI hardware" isn't an answer.  They have a reason.  What is it?  If you're wanting to use LVRT, the reason may not be valid.  If it is valid, LVRT may not be your solution.  From what you've given us, you're trying to force square pegs into triangle holes. 

---

I already programmed a system in LVRT that will solve my customer's problem; however, halfway through the project my customer decided that NI Hardware could not be used, saying that NI cRIO is unreliable and not robust enough for their system. I disagree, but I have to follow the customer's order, so I'm trying to save time/money by finding a board that can work with LVRT that is not NI Hardware; thus, not having to reprogram all of my code in another language.

[crossrulz]

---

@JHugh wrote:

I already programmed a system in LVRT that will solve my customer's problem; however, halfway through the project my customer decided that NI Hardware could not be used, saying that NI cRIO is unreliable and not robust enough for their system.

---

The cRIO/sbRIO meet a higher standard on reliability than a Raspberry PI or Arduino.  If reliability the requirement, then you actually need to be looking at embedded controllers specifically designed for military, aerospace, and/or medical.  Yes, this will make them just as or more expensive than the cRIO/sbRIO platform.  But if your customer adds this requirement, they should pay for it, including your wasted time.  Then we will see if their money is where their mouth is.