LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploy and run RT part of RealTime Project

Solved!
Go to solution

I'm developing a LabVIEW-RT Project, with a User Interface on the PC and time-critical code running on a PXI.  I've read a number of posts discussing the possibility (or lack thereof) of starting the RT part of the Project programmatically.  Here's what I mean:  my project has a Top-Level VI on the host PC, call it "Host UI.vi", and a Top-Level VI on the RT Target, call it "Target RT.vi".  There are the usual assortment of other RT features, such as Network Streams, Local and Network Shared Variables, etc.  

 

During Development, I open the Project, find the RT Target code, select Target RT.vi, and click Run.  I then do the same with Host UI.vi.  My code runs (or not, depending on whether I've introduced new bugs).

 

What I'd like to do is to run Host UI, and have it execute code to mimic selecting Target RT in my Project and right-clicking Run.  I've been partly successful, but one small step eludes me.

 

I can programmatically deploy my RT code, and have it pop up a Front Panel window so I can click its Start Button.  I've even managed to start it running programmatically using VI Server.  However, when I start it programmatically (instead of clicking Run), my Network Shared Variables are not available.

 

I investigated this a bit using the Distributed System Manager.  With it, I can "see" my Network Shared Variables on the RT Target, but its status is Offline.  I can bring it Online by clicking the "Start Process" button in DSM,  However, when I then try to programmatically start my Target RT vi using VI Server, the Ntwork Shared Variable goes Offline (accordint to DSM).

 

Question -- is there a way to programmatically do the equivalent of locating my Network Shared Variable in DSM and clicking Start Process?

 

[I had a Bright Idea while writing this post.  I noticed that if I deployed my VI and also deployed my Network Shared Variable, DSM showed it as Online, but when VI Server started the Target RT VI, the NSV went Offline.  What if I deployed it after starting the Remote?  Good idea, too bad it didn't work ...].

 

Any better ideas?

 

BS

 

0 Kudos
Message 1 of 7
(4,437 Views)

Hi Bob_Schor,

 

With Real-Time, there are a lot of possibilities on how you would like to accomplish this task.  One of these is to deploy what is called a Source Distribution to your PXI.  That will leave all of your code dormant until you dynamically call a VI from your PC using the VI Server.  You can also build your Network Shared Variables into the Source Distribution to be deployed when the VI accessing them runs.  Another method would be to create a startup executable on your PXI target that has the Network Shared Variables automatically deploy at run.  That startup executable would have code in it that waits for a "Go" signal from the Host PC to execute code.  After the code completes, it would return back into an idle state waiting for another signal from the Host PC to execute again.  This is a very common practice in industry for processes that need to run real-time but do not need to continue over and over again without interaction.  

 

I would consider the usage of a State Machine and a case structure waiting for a Network Shared Variable to be true before code inside the case structure executes.  Take a look through the options you have with Build Specifications in your project for the Real-Time controller.  You will be able to find some interesting options that may give you a good idea to accomplish the task you need.

 

Remember however, that any real-time application deployed to a target does not have a Front Panel.  That means you would need to create a Host PC VI to interact with the target VI through shared variables or network streams.  Please let me know if you have any questions about any of this.  I would be more than happy to help!

| Zach J. | Systems Engineer, HIL and Test Cells | National Instruments |
0 Kudos
Message 2 of 7
(4,376 Views)

Thanks, Zach, for the response.

 

I'm in "active development", making changes daily on both the Host and Remote Targets.  All of my code is in the Project -- what I'd really like to do is to "run once", i.e. open the Project (which opens My Computer), find the Host Top Level, and run it.  It would (a) find the corresponding Target Top Level VI (by its name) in the Project, (b) deploy it, and (c) start it running with VI Server.  This saves several steps and some time, and is easy to explain to a student doing testing to see if and how the code works.

 

What I do instead is open the Project, open the Target section, find the Target Top Level, click Run, go back to My Computer, find the Host Top Level, and click Run.  Not bad, but more complex, more time-consuming, a lot more mouse-clicking.

 

As long as I leave out Step (c) in the first paragraph, things seem to work.  I can programmatically deploy my RT code to the Target, I just can't start it running without killing the Shared Variable Engine that it is hosting.  Note that if I hit its "Run" button after the Deployment, things work.  Why does getting VI Server to do the Run kill the SVE?  I don't know -- do you have a clue why this should happen?  Is there a way to programmatically "restart" the SVE on the Remote?

 

One reason for wanting this flexibility is that I anticipate multiple "pairs" of Host/RT Target routines, where selection of a particular program on the Host will require a corresponding piece of code on the Target.  I think that the Source Distribution idea is quite reasonable for "mature" code, but I certainly don't want to be building Source Distributions over and over again during Development.

 

I most certainly am using a State Machine that monitors the NSV, particularly the one I call "RT Active".  I also have four Network Streams connecting Host and Remote -- two are used for Message Passing (each side has a Queued Message Handler doing housekeeping tasks), and two are reserved for the Remote to pass Sampled Data (e.g. A/D channels continuously collected) and Event Data (things that happen at specific times, such as the rise or fall of a Digital Bit, or the transition of a State Machine).

 

I'm just trying to do "more", and "better" (but am beginning to suspect that what I want to do LabVIEW doesn't (yet) allow).

 

Bob Schor

0 Kudos
Message 3 of 7
(4,360 Views)

Hi Bob,

 

That is a difficult situation you are in.  Normally, if you build a Source Distribution, all of these issues would go away.  Since you are working on your code still, I can understand not wanting to rebuild the Distribution with every change.  You could try disabling the automatic deployment of shared variables from your project, then run the code and test whether the Shared Variable Engine still continues hosting the variables.  Typically, Shared Variables will continue to stay deployed and hosted unless something tells them to become undeployed.  To do this, you can right-click your Real-Time target and select "Disable Autodeploy Variables."  You would then need to manually deploy the Shared Variables to the Real-Time target, but the VI's would not try to re-deploy or undeploy the Shared Variables afterward.  This may or may not be a solution to how you expect your functionality, but I think it might be the closest we can get without the use of Source Distributions.  Give it a try and let me know if, after you disable the autodeployment and deploy the rest of your code to the system, you are able to interact with the Real-Time target in the way you expect.

| Zach J. | Systems Engineer, HIL and Test Cells | National Instruments |
0 Kudos
Message 4 of 7
(4,346 Views)

Bob,

 

I'm working on the same problem and may have a solution for you. Check out this link:

 

http://digital.ni.com/public.nsf/allkb/5615C415DCEA0A2086257150006A0F7D

 

Use the 'Open Applicaiton Reference' vi and create a method. There is an option for Library, you can then pick Deploy Libraries.

 

I had been using a Method, referenced to my project to deploy Items that seemed to have the same problem you are having. The deployment pop-up would appear and act like it would as if I had right clicked from the Project, but didn't seem to actually deploy the Library. The method above requires you to have the file path of the library and IP address of the controller you are deploying to. Addittionaly, it runs in the background, so you don't get a deployment pop-up box.

 

For reference, I'm running LV2010 and testing this on a cFP-2120 controller.

0 Kudos
Message 5 of 7
(4,330 Views)

Yes, I tried that.  I programmatically deployed the top-level VI to the Remote Target, deployed the Shared Vairable Library to the Remote Target (and checked that the Library was still "on-line"), but as soon as I used VI Server to Run the Remote VI, the Shared Variable Library went "off-line".  I'm currently debugging other issues, but haven't 100% given up on doing this ...

0 Kudos
Message 6 of 7
(4,295 Views)
Solution
Accepted by Bob_Schor

Well, I just did it!  I have written a demonstration RT Project with the following characteristics:  The RT side consists of a single VI that sets a boolean Network Shared Variable (NSV) to False, goes into a While loop waiting for it to become True, goes into another loop waiting for it to become False, then exits.  The NSV is hosted in a Library on the Remote Target.

 

The Host does the following:

  1. Determine the IP of the Target from the Project.
  2. Given the name of the RT VI to run, return a reference to it.
  3. Use the Reference to deploy the RT VI to the Remote Target.
  4. Use the IP and the name of the RT VI to get a VI Server reference to it.
  5. Use the Reference to start the code running on the RT Target.
  6. Go into a loop looking at the NSV, and waiting for the Error Status to not be 8BBB0006 (uninitialized NSV).
  7. With the value returned from the NSV (should be False, set by RT code), negate it, set it, and wait for it to change.
  8. Do this one more time to return the NSV to its initial value (as set by the RT code).

Before running the code, right-click on the RT Target in the Project and turn on "Disable AutoDeploy Variables".  Zach J, an NI Applications Engineer, suggested this step, which may be the key step in solving this dilemma.

 

To test this, I rebooted both the RT Target and my PC.  Once both had restarted, I opened the Project on the PC, and without interacting with the RT section of the Project in any way (including not clicking "Connect"), I ran the Host code.  It started the Remote code, and told me that the round-trip time to set and reset my NSV was about 29 msec.

 

I plan to do a complete writeup of this and submit the entire Project, with documentation and all of the utility sub-VIs I used, to the NI Community page.  I'll try to get this done over the weekend ...

 

Bob Schor

0 Kudos
Message 7 of 7
(4,279 Views)