From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how does vi on target work

Hello all

 

 

I am working with a manipulator which runs with NI-PXI 8102rt controller on PXI 1031 chassis, I am provided with a labview interface from where I can give commands to move the manipulator.  I saw that  there is a main RT.vi in the project  under the target NI-PXI8102 , and inside this mainRT.vi  all the code required for implementing the functionality of the manipulator is present (I could see by opening it).  But when I use a 'vi' under My Computer folder, to move the manipulator, I don't see mainRT.vi running in my PC (But the code inside mainRT.vi is required to move motors of manipulator), Is this vi(mainRT.vi) running inside controller? If it is true,  Please let me know, how to change something in the mainRT.vi so that I can change functionality of my Parallel manipulator .  If it is not , help me understand how mainRT.vi and mainFPGA.vi under target NI-PXI8102 work along with a 'vi ' (under My Computer folder) when it is run. I am attaching a snapshot of my Project.

 

 

Any suggesions on how to proceed is appreciated.

 

 

Thanks and Regards

 

 

 

0 Kudos
Message 1 of 5
(2,881 Views)

A LabVIEW project can have multiple targets - a 'target' could be your PC, an RT chassis or an FPGA (or even something else!). You write VIs for each target (there are some differences on RT, and lots of limitations on FPGA as to what you can do).

 

When you run code on an RT target, you must deploy that code to the RT target. When you press 'Run' on an RT VI, you'll see the deployment window as it downloads the VI to the target and runs it. You can either deploy manually in this way, or you can build an RT Executable (rtexe - under build specifications) which will package up your VIs which you can then deploy to the target and then set to 'run as startup'. 

 

FPGA VIs work in a similar way - but they need to be compiled using the FPGA toolkit which takes time.

 

The code running on the PXI is probably an RTEXE - to make changes to it you will need to modify the mainRT.vi and/or it's SubVIs and then re-compile the RTEXE which you can then deploy/run as startup to get it to execute your new code when the PXI boots up.

 

The RT/FPGA VIs interact with your 'My Computer' VIs via network communications - it could be network streams/TCP/IP or by opening the FPGA reference directly.

 

I suggest you take a look at the cRIO developers guide - it explains the different 'components' of an RT system (e.g. PC/RT/FPGA) and how they interact. https://www.ni.com/compactriodevguide/


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 5
(2,838 Views)

Yes, Sam summarized it nicely.  When I started doing LabVIEW RT, it was with LabVIEW 7.0, and we saved our LabVIEW code that ran on the PXI in an .llb on the PXI.  We could have multiple .llbs, and at Run Time, the code on the PC "started" the code running on the PXI by making a call through VI Server to run the appropriate "Top Level VI" in whichever .llb was appropriate.

 

When I (fortunately) "migrated" to more modern versions of LabVIEW that utilize LabVIEW Project, it took a while for me to wrap my head around the concept that you now treat the RT Target differently -- you deploy your code to the PXI, then set it as the "Startup" code to run when the PXI is rebooted, with the final step in the deployment process being the rebooting of the PXI.  The concept that the Host doesn't start the code running in the PXI, but rather that when the PXI is turned on, it starts running one particular piece of code, was not a comfortable notion, but now I'm used to it.

 

I've even learned to Have My Cake and Eat It, Too.  We actually have several versions of our Data Acquisition code, depending on precisely the study we are doing.  For each Version, I build a separate .RTEXE, name them differently, and deploy them in separate folders on the PXI.  When the main PC code starts and connects to whatever is running on the PXI, they exchange identities ("Are you Version 2.3?  No, I'm Version 2.1.  OK, I'll tell the Experimenter to fix things ...").  I wrote a little utility called "Reset PXI" that interrogates the PXI to see what code it runs on Startup, informs the User, and allows the User to choose another routine.  All the code has already been deployed, it is just a question of changing the ni-rt.ini file to make the chosen RTEXE the Start-up routine and then rebooting the PXI.  True, you do have to wait the minute or so while it reboots, but we typically don't switch our paradigms that often ...

 

Bob Schor

0 Kudos
Message 3 of 5
(2,807 Views)

Thank you sam. I'll go through the link.

0 Kudos
Message 4 of 5
(2,776 Views)

Thank you Bob

0 Kudos
Message 5 of 5
(2,773 Views)