Linux RT Desktop Deployment

[Hooovahh]

Sorry if this is a duplicate idea I searched and couldn't believe it hasn't been posted.

This idea is to add Linux RT deployment support for desktop PCs.  NI in the past has had a process for purchasing an Phar Lap RT license, then deploying it to a normal x86 based PC.  Here are the System Requirements, and a manual.

This opened up the door for desktop PCs to become embedded PCs, controlling NI hardware, but allowing for an upgrade path where embedded cDAQ devices, and even PXI controllers don't have many options.

At the moment there are unofficial ways to get Linux RT on an x86 based desktop with limited success, but no support.  These options are outlines in the comments of an idea to allow for a VM of the Linux RT environment.  NI could go with a similar route to Phar Lap and sell a license with a list of supported hardware.  

[cy...]

agreed to certain degree... but if NI intend to grow the user base, perhaps better to offer free major releases that will be supported by the community after release (education/hobbyist/enthusiasts), and charge for only the enterprise/NI professionals supported licenses...🤠  

[nanocyte]

My use case for this is I want to build an image for my sbRIO without having the physical hardware for each target. So for example, lets say some of my customers are running on 9627 and others are on 9628...I could have a virtual 9627 and a virtual 9628 and make builds for both targets somewhat automated without having a rack of real, physical sbRIOs.

[cy...]

@nanocyte: you can do that in LV already

[Hooovahh]

You can make a build to a target in the Project Explorer.  But you can't deploy that build, and see that it actually runs or functions, without a target to deploy to.  I've had several builds that get built successfully, but then when ran on the target either don't run, or crash immediately.  In these cases I need to clear the compile cache and build again.  This type of Continuous Integration testing could be automated if there were dedicated targets to deploy to.

[nanocyte]

Also, you can make the rtexe but you won't be able to create an image to distribute. This is useful if you want to distribute a new LabVIEW RTE version along with the rtexe

[cy...]

if that is the case, wouldn't simulated LinuxRT RIO devices can also be applicable, since the IO already not matching in between a PC and intended RIO device? simulating in the same PC save one PC

for my intended use case, I am looking at the use the LinuxRT PC as an automated vision inspection system, with generally better processor, more memory, more USB3s, coupled with a RTOS, and DAQmx or PCI card supports for NI hardware, (or even VISA, OPC?), to offer NI some motivations to explore this... for additional license & hardware sales

I have tested Vision on LinuxRT cRIO before, it was fantastic, albeit the limited image size and low frame-rate video, and limited cameras...

[Hooovahh]

If you build an RTEXE, how can you know it was built correctly?  You need to deploy it to a system, and do some unit testing on it.  If you had a PC, or a VM that was this Linux RT environment you could deploy to it, and do some network communication to see that it is running.  For a vision system you could also pass in some static image files, or a video, that could be used instead of the camera, and see what the result is.

[cy...]

I am just suggesting a simulated device can also serve the purpose; by simulated here means it can be added to the project tree as if the physical hardware is present. it can be a VM, to save some hardware, and embedded UI can be access through vnc (forgotten the name of the last one I used).

a simulated programmable switch for 10/100M/1G can help simulate the throughput virtually, and if it can help to visualize the chokepoints (by showing %utilization), that would be a plus. this approach can be more scalable when the number of instruments increases... hmmm... perhaps I should post another for pre-deployment virtualized testing