LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Kudoed Authors
User Kudos Count
1
1
cancel
Showing results for 
Search instead for 
Did you mean: 

Provide a Virtual Machine (VM) in which to run LV RT systems on

When developing RT code (especially system upgrades) it would be truly helpful to have a virtual machine (VMware, MS Virtual PC, Sun Virtual box, etc....) that would allow us to run the actual VxWorks OS and LVRT in it's native environment, within the Windows OS. This would allow the code to run on the actual RTOS (I realize that determinism would be scacrificed) and provide the ability to actually test the functionality of the code in the actual environment to ensure that it runs as it should. It would also preclude the need to have a bunch of RT controllers sitting on the shelf in the event that you might need them.

 

There is and emulator for PDA module, why not for RT.

16 Comments
Member

What support would you expect from this type of simulation environment? Do you simply want to run LabVIEW code and have it feel the same from the LabVIEW Project? Do you require access to simulated I/O? Do you need to also test your own libraries (.dll or .out)? Do you want to simulate several targets communicating over a "network"? What about multicore support?

 

Also, you call out VxWorks specifically? How critical is it that the RTOS running in this Windows simulated environment be the same as the one on the RT target (since LabVIEW abstracts most of the OS differences away?) Currently, NI only uses VxWorks on PowerPC processors.  Running VxWorks within a Window x86 environment would be a completely new beast.

 

thanks

Kevin Johnson
Section Manager: LabVIEW Real-Time R&D
Active Participant

Simulated I/O would be nice but to allow as complete of a test as possible, but I think that I could do without the I/O if that were the make or break point for this becoming reality. Most of the code I build has the ability to simulate it's own signals internally. A link through the driver would be nice but I wouldn't consider it a hard fast requirement. 

 

The ablity to test and run 3rd party libraries (.dll and .out) should be part of the minimum requirements.

 

Running the same RTOS as the designated target seems to go hand in hand with the .dll and.out support. If I am developing a .out file for my VxWorks target, the VM should be capable of running it on VxWorks.

 

With respect to the simulation of multiple targets over the networks, it would certainly be a nice feature, similar to settting up a team in VMware workstation, however I think one system at a time would suffice for the vast majority of situations.

 

TCP/IP would be an absoloute requirement.

 

 As long as I am wishing, the ability to downgrade the processing capability of the VM to better simulate the performance of the actual target would be a real plus. This would give the developer a better idea if the CPU is being overtaxed by a particular application. Running the VM on a quad core i7 CPU may work just fine, only to find out that on a cFP-2220,  the CPU is fully maxed out.

 

 

The primary purpose of this virtual RT system is to as closely as possible emulate the way the actual system will run on the target hardware (determinism notwithstanding). There are known differences in the way LabVIEW operates on Pharlap, VxWorks, and Windows, so the idea is to be able to flesh out those issues before hitting the real hardware.

Member

I think this is an excellent idea, and we have been considering this but as KJ_Vandy mentioned, it would require non-trivial work.

 

In the meantime - have you considered purchasing a LV RT/FPGA embedded eval kit to serve your needs? You can think of it as a stripped-down single-board RIO with less features and less rigorous testing, i.e. it's not designed for deployment. It's relatively inexpensive - $999, which I assume you would be willing to pay for the simulator you describe. It has the added benefit of giving you a processor comparable to your final deployment platform as well as the FPGA and some limited I/O. 

Active Participant

Purchasing a sbRIO only serves to add to the list of hardware that must be kept on the shelf. If I were looking for a system for a small project, this might be just the ticket, however for the purposes of this discussion the sbRIO is really a Band-Aid, good only for VxWorks platforms. 

 

I believe that the virtual machine approach fits well into the currently required model for supporting multiple development versions of LabVIEW and associated drivers. I realize it might require a considerable effort on NI's part, however from a development and support standpoint the value would be very high.

 

It would also allow multiple versions of the VM to be stored with specific customer installations and driver sets which would preclude any issues due to system upgrades with mismatched driver versions or API compatibility.

Member

This should be easy. Windriver provide VxSim - which is a vxworks simulator.

 

What I would like to see is an option to right click on the target and choose "Execute VI on Development Machine" as for the FPGA target

Member

Hi,

I think I have I have a slightly different take on this, perhaps less demanding on NI resources.
I find building and especially deploying sometimes very time consuming.

What I would like to see is the possibility run pharlap ( and vxworks)  in a virtual machine, similar to the RT Hypervisor I guess but for a different purpose.

I would rather compare it to being able tu run a desktop ETS system as a VMware virtual machine.

There is so much work in building for LV RT on PXI that could be tested in this way, packed librarys, dlls target-host communication etc. The most time consuming challenges I have had, have involved getting our code to run (application startup, not I/O or anything) as a built .rtexe when it runs perfectly from the development envrironment.

 

Member

This is an awesome idea! One of the things you can do to create an RT target is use MAX to make another PC computer into an RT target.  You wont have I/O but at least it would be an RT environment. You can see how to do it here: http://zone.ni.com/wv/app/doc/p/id/wv-309

Certified LabVIEW Architect
Certified Professional Instructor
Member

I use the Oracle VM Virtualbox for Virtual Machines.

 

In this way, different LabVIEW Installations are easy to maintain.

 

I'am waiting for a possibility to install Pharlap or VxWorks to this VM!

Active Participant
Status changed to: In Development
 
Deborah Burke
LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
Member

It is possible to (I was able to) install LabVIEW RT on an Oracle VM. This is the procedure I've used.

Ceate with MAX the Desktop PC utility USB Drive. Created a VM with a supported network interface card (set it to Host Only); put inside the VM a SATA controller and create under this controller the virtual disk that will be used as primary disk; put inside the VM an IDE controller (this will be used only for the first boot).

Create a .vmdk file that enable the direct raw access to the usb stick. (detailed info here http://www.howtogeek.com/187721/how-to-boot-from-a-usb-drive-in-virtualbox/)

Use this .vmdk as the primary disk under the IDE controller.

Start the MV, the utility disk should now boot. Format the disk of the VM in reliance mode. Shutdown the VM when done.

Remove the IDE controller from the VM. Restart the VM, now it should boot from it's virtual disk in safe mode.

Configure and instal sw with MAX as a regular RT target.

 

If you have problem with the acquisition of the IP address setup a DHCP server on the virtual network adapter (here you can find a freeware and easy to use tool www.dhcpserver.de)

 

Hope this will be useful for someone.

 

VM cfg overview

 

VM running VeriStand