12-07-2016 03:48 AM
Hello everybody out there using NI Real-Time.
It's only my annoying point of view but I think also that NI should provide an official standard VM for the 3 RTOS (PH-Vx-LxRT), at least for partners and customers.
It would be limited, circumscribed. We could humbly modify the core numbers or the amount of memory. It should be interesting. And fun.
It is not like having a complete and complex virtualized environnment for NI hardware, like the Hypervisor.
It does not decompartmentalize the offer.
It is most a question of expanding the LabVIEW RT usability by decreasing implementation costs with a touch of creativity.
And around building services as a real-time operating system provider as you are with selling licenses.
It could means to great benefits in a target-development process : soft-testing, debugging campaign, credible simulated I/O, deported and planified integration, deported and planified hard-testing, saving sources, cloud services, "old software" improvement, portable devices, travelling demos, multi-developer coding, avoid punctual machine needs, multi-targets projects, large system implementation, storage, saving times, various costs...
A learning tool for an official NI RTOS formation on-the-go.
Maybe a university hardware costs prevention bundle ?
Or a handy and accessible packaged development platform for independant developers in middle-low budgets projects.
New far, far away futile platform horizons.
Networked zybo boards of numerical and simulated physicals signals ? A few I/Os. With statistical or time-frequency analysis. And a screen. Kind of a small field toolbox. Closest to the measure. Starting useful cute product.
And fully compatible into the NI platform as third party hardwares. A kind of NI Insight Product Manager.
A NI Field-programmable-gateway-array programming language.
Low profile I/O's deterministic deep-processing farm over Tegra's Cuda ?
Maybe only for the 5-minutes-left-darlin' homework. (the Christmass curse)
Sorry to digress. Just sample ideas to debate. Or to work onto.
Who knows.
12-07-2016 04:57 AM
At least VxWorks and the ARM NI Linux RT variant are technically pretty impossible to do. All NI VxWorks targets use a PowerPC processor and adding a CPU emulation layer to the virtual machine environment is certainly going to be a long stretch to ask for!
While there are some systems out there that attempt to do this, they either are semi functional or very expensive and sometimes both.
12-08-2016 09:33 AM
Oh. You're right. It's funny. I didn't know about the PowerPC processor. Thanks to you to underscore my mistake.
I know I have too much imagination. My bad, too much time.
I just like learning process, sain ecosystem and free knowledge.
And it doesn't cost anything to ask.
Let's back to work.
12-20-2016 08:04 AM - last edited on 05-09-2024 10:13 AM by Content Cleaner
Well with the help of a few members of the community, and a healthy discussion on LAVA, there has been discovered a way to install an Linux RT OS in a VM, and connect, deploy, and run LabVIEW code on it. There are several limitations, but it is a great start, and can help out those new to RT, and new to Linux, discover how to install, and develop code around 3rd party software tools. The whole discussion thread is here, but here is the summary of what is needed.
Once restarted if you have LabVIEW 2015 (non-SP1) installed on your host OS, then you should be able to connect and deploy code from LabVIEW, but I needed to upgrade to 2015 SP1 and the VM isn't recognized by MAX as a remote target so we need to manually update the VM.
I wanted to upgrade to 2015 SP1 so I transferred over the lvrt and the liblvrt.so.15.0.1 files from the following directory: C:\Program Files (x86)\National Instruments\RT Images\LabVIEW\2015sp1\Linux\x64\
Next we need to recreate the symbolic link we deleted earlier. So using putty log into the VM, and navigate to the /usr/local/natinst/labview folder and execute the following command.
ln -s ./liblvrt.so.15.0.1 ./liblvrt.so.15.0 Then reboot the VM.
Now the VM has the LabVIEW 2015 SP1 runtime engine installed, and more importantly it matches the version my Windows machine has installed so now we can connect and deploy with a few more steps.
Now in LabVIEW you can develop code, and deploy and run to the VM target. I tested it running the system exec "ls" and it listed files as bash should. I've also been able to deploy code that uses TCP, UDP, WebDav, Network Streams, DataSocket, and VISA functions so these libraries are installed with the ISO, but no DAQmx, not that this VM needs it.
As for limitations. MAX won't allow installing new software, so installing any NI software needs to be done manually, and will be a pain. As far as I can tell the XFCE UI isn't included, so there is no UI. Installing one might be possible but normally this is enabled in MAX which doesn't recognize it as a remote target.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
12-23-2016 09:02 AM - last edited on 05-09-2024 10:14 AM by Content Cleaner
Thanks for posting the results of your findings, Hoovahh. I can see that some are probably already using your work (see: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/opkg-force-downgrade/m-p/3562453#M2114).
12-23-2016 10:14 AM
I don't think that is necessarily true, that looks like just a terminal like putty which could be connected to a remote (and real) system.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
12-24-2016 08:39 AM
Sure, but that's be a weird hostname to give to an actual pxi target....
01-03-2017 08:06 AM
Ahhh didn't notice that before. Well glad some in the community are able to experiment with using this OS in a VM.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
08-29-2017 03:21 AM
Hello all,
After reading your discussions, i am attempting to make a VM which simulate a Linux RT CompactRIO.
I started by making a clone of a cRIO-9030 that i have with CloneZilla, made a bootable recovery iso and done the recovery in a vdi disk image in virtualbox.
Then, when i start the virtual machine i get the message "FATAL : No bootable medium found"
Do you have some idea on how to make this vdi bootable ?
Thanks
08-29-2017 04:15 AM - edited 08-29-2017 04:20 AM
I'm not sure you can make an image build for a cRIO run on a VM. The cRIO as well as the Linux image are both made by NI and Apple has shown how to make it almost impossible to run a MacOS X image on a VM that is not hosted on a real Mac.
There are many things that the NI Linux RT could do during boot up that are very specific to a NI Linux RIO hardware.
I haven't really spent much time with this, as an interesting project as it is, but I had quite from the beginning a hunch that it might be pretty impossible to get a pre-built cRIO image to run under any VM. Most likely the way to get there is to actually grab the sources for the NI Linux RT kernel and compile it yourself for a generic PC.
And after that to figure out what NI runtime libraries, drivers and what else needs to be copied over to that system. This is a tedious and painful process, not to speak about the fact that it requires a license from NI to run such a system. LabVIEW RT runtime, NI VISA, NI-4882, NI-RIO, NI-this and NI-that are not free software. They come with the RIO hardware that you buy from NI but if you don't buy that hardware you don't have a license to run that software on another hardware including a VM. And it doesn't matter that you can download some of these drivers for free from the NI site. Those "free" downloads are generally meant to run on a Windows or Mac system and will not run on a Linux RT system. These drivers are partly part of the LabVIEW Realtime system and partly of the device drivers for the NI realtime hardware and not only technically tightly tied to that hardware but also in terms of licenses if you read the legalize for those software packages.
And while NI certainly isn't sad that these drivers are in fact quite tightly tied to their hardware it isn't even malice that they are. Creating a driver that would technically work on many different hardware targets is a lot more complicated and expensive than making it work for specific hardware only. Since there is absolutely no incentive for NI to do that, why should they spend the extra expenses of making their drivers also work on other hardware. Especially the testing part is very costly for that.