LabVIEW Real-Time Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
gsussman

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

Status: In Development

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.

73 Comments
andre.buurman@carya
Active Participant

Yes,  the cRIO as VM can't be discovered by NXG in live view via the add hardware menu.

 

Were you able to connect NXG to a real cRIO using the same SW stack?

Regards,
André (CLA, CLED)
nwxan90
Member

I haven't managed to get into the office yet to try on some real hardware. 

 

Latest update is that I can see the system in the live view tab when running NXG image. Looks like everything populates correctly 

Live View cRIo NXG.png

 

When porting it over to system designer it shows as an available live system

image.png

 

However when placed down it shows as not matched and still shows as available in the unplaced live hardware.

Not Matched.png

If you try to manually add it you get the same error as before when it shows as the VMs network card and not the cRIO. 

 

I feel like we are so close 


Certified LabVIEW Architect, Certified Professional Instructor

CLA CPI

fmorandat
Member

nwxan,

 

Maybe it's just too early.
But I think there's big steps here, and some good news.


It's hard for me to follow you, I would like to be sure :
- So, a "standard" LabVIEW 2020 VM is recognized by NXG 5.0, but with software issues ?
- Your last update said that finally you can see the NXG image in the live view tab, but how ? It was your windows install/firewall issue ?
- Which VM software do you use if VMware Fusion and VirtualBox don't fit ?
- Which legitimate files are you using, if you use some ?

andre.buurman@carya
Active Participant

Could it be related to the fact that part of the system that is available in real HW, like FPGA, raises an internal error preventing it to continue?

Regards,
André (CLA, CLED)
nwxan90
Member

Hi fmorandat,

 

-Yes a LabVIEW 2020 VM is recognised but it shows as incompatible software. I suspect that this was a red herring though as now that my NXG 5.0 VM also shows in live view

 

-The NXG VM wasn’t showing up before I suspect because of firewall issue on windows. As connecting to

 

- I have tested using VM ware fusion and using VirtualBox for running the Linux RTOS VM. Below is my full setup with all networks. In the below image both VMs are running in VMWare Fusion for Mac.

 

(I also have tested by Nesting the RTOS VM inside of the windows VM using VirtualBox however the outcome is the same)

nwxan90_0-1591711783872.png

 

 

-I have not pulled any files from legitimate hardware as of yet however I think the edits I mentioned above to the grubenv file is all that matters for making it appear as the correct hardware as it allows the NXG image to be flashed over

 

@André you could be correct maybe in the next release it will work. I think its safe to say what we are trying to do is VERY not supported


Certified LabVIEW Architect, Certified Professional Instructor

CLA CPI

andre.buurman@carya
Active Participant

It somehow relates to the fact that discovering the cRIO Vm in e.g. LV 2020 in a project (add target - discover). This fails.

Adding the device and then entering the IP address makes it work as expected.

 

Somehow NXG is trying to be too smart for us and alwasy wants to discover itself instead of trusting us and have us just configure the IP settings in design mode and have it be connetable.

 

Somehow the discover function doesn't find everything it wants and errors out.

Regards,
André (CLA, CLED)
fmorandat
Member

Crazy 😂

 

I had the surprise that my PXI VM is officially supported in NXG 5.0 and is recognized in the System Designer.
So, in the doubt...


Connected in System Designer :

SystemDesigner.png

Running in source :

SourceRunning.png

 

Build and Deploy :
BuildAndDeploy.png

 

Classic conflict in source after build :

ConflictWithBuild.png

 

Also, the desktop UI will start with the previous command.

But I don't know yet how to show the vi front-end in NXG 😅.

 

How to do is a bit tricky and maybe not the best way :

-> After installing the cRIO-9040, use these variables in the grubenv file :

GrubenvVariables.png

fmorandat
Member

Small update about the UI after testing : it's not usable because of the target type and because NXG can't run the source code when the linux desktop is activated, which is a bit surprising.

andre.buurman@carya
Active Participant

White smoke for a Virtual cRIO in NXG 5.

 

I changed DeviceDesc to NI cRIO-9053 (don't know if it was necessary.

I remove the host-only network card from the VM, so it only had the bridged card.

Using the add HW with the found cRIO didn't work (not compatible), but the adding by IP address seemed to work.

From live via to design view it showed as "no match", so I disabled hardware matching (orange symbol).

Somehow it now allowed me to run a VI on the target and build and run the exe on the target.

 

The RT app (rtexe) using the SystemLink message API to continuously send it's current time and the client app running on Windows subscribed to the message topic and displays the time. The SystemLink server is our demo server running somewhere on the web, so communication between VM and Host is going over the internet.

 

NXG 5 cRIO in VM.PNG

 

Question remains: Why can't NXG match the hardware? What properties does it use to match?

Regards,
André (CLA, CLED)
nwxan90
Member

Thanks for the tips I can confirm your findings that swapping to a PXI based target does indeed allow it to be correctly identified in NXG and I can deploy code onto it. 

 

It shows as a PXIe-8840 when discovering hardware (I chose a different device code and description as I don't think the PXIe-8135 is supported in NXG?)

PXi Detected.png

 

The code defiantly deploys as I made a simple VI to add two numbers in a loop with no timing and you can see via TOP that the code is running as per the below. 

Top Runnig .png

 

I have been editing my grubenv file using the below command from http://manpages.ubuntu.com/manpages/cosmic/man1/grub-editenv.1.html

 

grub-editenv - set TargetClass=PXI

 You can confirm that you have made your changes by using:

fw_printenv

I also had the same issue though that after enabling the remote UI I can no longer run the code as it throws the error "Failed to establish debugging session" when trying to run it in source. The deployed app will still run but nothing is shown on the UI. 

 

I wonder if the embedded UI is not currently supported in NXG


Certified LabVIEW Architect, Certified Professional Instructor

CLA CPI