What boards other than cRIO can run LabVIEW RealTime?

[rolfk]

Your customers reasoning is somewhere pretty flawed. More reliable hardware than cRIO definitely comes into MIL-Specs. Almost all of the single board controllers out there come nowhere close to both reliability as well as long term availability of the NI controllers. Yes NI obsoletes its controllers too from time to time but where this period is counted in 5 years or more for NI hardware, you need some luck to get the same hardware that you ordered a few months before for most of the "standard" embedded controllers out there and even worse for anything labeled PC compatible.

And for anything but a hobby project it's simply legally not sound to try to get the LV Realtime runtime system to execute on non-NI hardware except for the LabVIEW Pharlap ETS system.

With all that in mind, the only option for you to keep using LVRT and your own controller hardware would be to find a controller that is compatible with the LabVIEW Pharlap ETS specs (x86 based CPU, correct Ethernet controller) and then build on that. Expect a few bumps on it, and since the controller is basically a PC compatible device, to purchase whatever amount your customer plans to use in total in the same shipment to be sure to at least have the same hardware for all of them.

But if reliability is really your customers point, then you will be hard-pressured to find a controller board that matches a cRIO's reliability and be not more expensive than the cRIO.

[JHugh]

Yes.

I just have one last question. If we do end up using Pharlap ETS RT, will we still have access in our program to the NI device drivers and blocks i.e. NI VISA, TCP/IPv4, File Management Blocks?

[rolfk]

TCP/IP you can directly access through the TCP LabVIEW nodes. NI-VISA should work too at least for serial and TCP/IP. GPIB might be problematic except for the GPIB-ENET and maybe the GPIB-USB interface. Same about DAQmx which should work if you use a network connected NI-DAQ device, maybe with USB connection, but most likely not with other interfaces. IMAQdx is most likely troublesome. The IMAQdx driver for Windows uses DirectX for this and won't work with Pharlap ETS for this reason. The Pharlap ETS drivers for IMAQdx are specifically made for the NI smart cameras and won't work with other camera hardware. Writing your own device driver for Pharlap ETS is not really an option for most people. It would require to purchase a Pharlap ETS development license, something where your LabVIEW license looks cheap in comparison. Also Virtual COM devices connected to the USB bus are not likely going to work either. The LabVIEW File IO blocks work fine and so does the Win32 File IO API if you use DLLs that make use of that.

[natasftw]

Adding on to rolfk...

After you consider all of those borderline solutions, you're stuck with two questions.

1) Is this a more cost effective solution?

2) Is this a more robust solution?

If the answer to either is "no," you're doing wrong by your customer to give them this solution even if it's what they're asking for.  They're clearly making an uneducated decision if either of those aren't true and they're pushing for this path seeking a more robust solution.