LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploying local shared variables on a real-time target

Solved!
Go to solution

Hello again all,

 

I've read more posts and knowledge base articles on this topic than I can count at this point, and I'm afraid I'm still not clear on exactly how it works, and I'm hoping someone can clear it up for me, if only to earn themselves some more Kudos.  Smiley Wink

 

I have a project with a real-time side, and a Windows side.  They communication via network-published shared variables.  The real-time side also uses single-process shared variables to communicate between loops.  I intend all 3 shared variable libraries (Windows -> RT, RT -> Windows, and RT Local) to be hosted on the RT target for reliability.  The real-time executable has to start at powerup and run even if the Windows side is not started (the Windows side is optional).

 

I've figured out that the real-time executable will not start the shared variable engine and/or deploy the shared variables itself.  I've also read that I cannot deploy the shared variables programmatically from the RT side.  That leaves only two options as far as I know:

1) Programmatically deploying them from a Windows-side program.

2) Deploying the shared variables onto the RT target manually via the project in the LabVIEW development environment, and

 

Regarding option 1, as I said the Windows execution is supposed to be optional, so having to run a program on the Windows side before the RT side will work is highly undesirable.  Besides, even if I make a small "Deploy shared variables" app that runs on Windows startup, I cannot guarantee that it will run before the RT side startup executable will run.  In that case, will the RT executable fail due to not having the shared variable engine running?  If so, and the Windows side then starts the engine / deploys the shared variables, will the RT side then start working automagically?  If not, is there some way to trigger it to restart from the Windows side startup application?

 

Also, I just read about and tried the option to build deploying the shared variables into the Windows side application.  Not only was my RT Local shared variables library not listed as an option (since the Windows side application did not reference it at all for obvious reasons), but when it deployed the other two libraries on startup, the RT side program (which was running in the development environment) halted.  I'm not positive the same would happen if it was running as a real executable, but it's certainly enough to make me nervous.  I suppose the library not being listed might be solved by including one network-published variable in the RT Local library and including that in the Windows side app.

 

Regarding option 2, I don't understand how I am supposed to deploy my shared variable libraries without stopping execution of the startup application on the real-time target.  Once I have done so, the only way to restart the RT application is to restart the RT computer, correct?  In which case, I just undid the whole point of deploying the shared variable libraries?  Unless the libraries stay deployed and the shared variable engine running even after the RT computer is rebooted, which would solve the problem I guess.  Definitely let me know if that is the case.

 

However, option 2 is complicated by the fact that when I manually right-click on any of my shared variable libraries, and select "Deploy" or "Deploy All", the libraries still do not show up in the Distributed Systems Manager, even after I hit refresh a few times, on either the local system or the target system.  The only thing that shows up, on both sides, is the "System" group, with FieldPoint, etc. in it.  The same is true when I am running my real-time application in the development environment, even though the shared variables are clearly working, as I mentioned earlier.

 

So, if you've made it this far through this mammoth post, thank you!  I have three main questions:

1) Are all of my descriptions above correct with regards to how shared variables work?

2) What is the best way to satisfy the requirements I outlined above for my project?

3) Why aren't the shared variables libraries showing up in my Distributed Systems Manager?

 

Thank you for any help you can give on any of those three questions!

 

-Joe

0 Kudos
Message 1 of 18
(8,782 Views)

Yes I understand your frustration as I have gone down this path also.

 

The solution is to get your RT target up and running from the LV Project first.  That means deploying NSV libraries manually and setting the RT executable to run on startup.

At this point your should be able to use the DSM to verify your NSV deployment.  If not then something is wrong on your network or the RT target has not started the SVE correctly.

Once you have it running, then you will need the RTADU

 

http://decibel.ni.com/content/docs/DOC-5102

 

which allow you to exactly replicate and redeploy your RT application, including NSV deployment images.

 

On the windows side, when you do a build make sure that the auto deploy SV's option is turned off so that the exe will not try to redeploy to the RT target which as you noted will shutdown

your rt app.

Message 2 of 18
(8,768 Views)

sachsm,

 

Thanks for your response.  I have some questions:

 

1) If I deploy my network shared variables (NSV) manually from the LabVIEW project, does that start the Shared Variable Engine (SVE) on the target machine automatically?

 

2) Can you think of any troubleshooting I can do if I deploy the NSV and they do not show up in the Distributed Systems Manager (DSM)?

 

3) If, after deploying my NSVs, I reboot the target machine to get my startup executable running, will the NSVs still be deployed and the SVE running when the target machine starts up again?

 

Thanks again!

 

-Joe

0 Kudos
Message 3 of 18
(8,760 Views)
Solution
Accepted by topic author jmorris

1. Yes, as soon as you deploy from the project then the NSV's are tranactional.  The SVE is loaded by MAX when you configure the RT target and will start running as part of the boot sequence.

2. Can you see anything on your rt target in the DSM?

3. Yes, NSV's and the SVE are persistant across reboots.

Message 4 of 18
(8,756 Views)

saschsm,

 

The only thing that shows up in the DSM, on both the local and target side, is the "System" group, with FieldPoint, etc. in it.  The same is true when I am running my real-time application in the development environment, even though the shared variables are clearly working, so they must be deployed and running somewhere.

 

-Joe

0 Kudos
Message 5 of 18
(8,751 Views)

Hi jmorris, 

 

If I have missed it, I apologize for making you repeat yourself, but after reading through your posts, I am still unsure what your RT Target is... is it a RT desktop?  How do you have it connected to your Windows machine? This sounds like the target itself is not being recognized. Can you see the target in Measurement & Automation Explorer? Thanks!

 

~kgarrett

 

District Sales Engineer
0 Kudos
Message 6 of 18
(8,737 Views)

kgarrett,

 

No problem, I appreciate your trying to help!

 

My application is deployed on a PXI Hypervisor computer, so the RT target is 3 of the 4 CPU cores of the computer, with the 4th core running Windows and the other side of my application.  They communicate over a virtual ethernet connection.

 

I can see the RT target in MAX, and have verified that both the Network Variable Engine 1.7.0 and Variable Client Support for LabVIEW RT 1.7.0 software are installed.

 

-Joe

0 Kudos
Message 7 of 18
(8,733 Views)

Hi kgarrett,

 

I can offer some help here as well; I manage the LabVIEW Real-Time and Real-Time Hypervisor products at NI. To others reading the thread that may not be familiar with the Real-Time Hypervisor, it is a piece of software that enables running LabVIEW Real-Time and Windows in parallel on one PXI or industrial controller (http://sine.ni.com/nips/cds/view/p/lang/en/nid/207302). The important thing to note is that the presence of the Real-Time Hypervisor shouldn't affect the issue mentioned in this thread; both the LabVIEW Real-Time and Windows applications as well as networking should work just as with a typical LabVIEW Real-Time system and remote host.

 

You can host your Shared Variables on the LabVIEW Real-Time OS or on Windows. If you choose to host them on LabVIEW Real-Time, then as some others have mentioned I would recommend pre-creating the variables either manually or using a Windows utility. The variables will persist across reboots. If you choose to host your variables on Windows, then you can pre-deploy the variables manually, deploy them programmatically via a utility application, or use an installer that you have built to automate the creation of the variables. The variables will also persist on Windows machines.

 

If you need to set up a bunch of LabVIEW Real-Time targets and do not want to manually create variables on each of them, then you can use the System Replication VIs after setting up only one system -- and then copy that one system across other systems. If you need to replicate an entire hypervisor system (Windows and RT sides), then you can create an image using the directions here (http://zone.ni.com/devzone/cda/tut/p/id/12288).

 

In short, programatically deploying shared variables should not be needed in most cases, but is possible from Windows if needed. Shared Variables are most often deployed manually or during the development process, and then persist on the target for later use.

 

A few other helpful notes:

- In order to see any Shared Variables on your real-time target using the Distributed System Manager, you need to install a software component on your LabVIEW Real-Time target from MAX (I'll have to look up the name, but the description should be clear)

- To deploy or access Shared Variables on your real-time target, you also need to install software components on your LabVIEW Real-Time target from MAX

 

Please let me know if you have any additional questions, and I'm glad to help moving forward.

 

Best Regards,

 

Casey Weltzin

Product Manager, LabVIEW Real-Time

National Instruments

Message 8 of 18
(8,725 Views)

Casey,

 

Thank you for your very nice summary of the answers to the first two questions of my original post!  Between you and sachsm I think I've got those concepts understood at this point.

 

The only remaining issue is why my shared variables are not showing up in the Distributed Systems Manager (DSM) after I deploy them to the RT target.  The Network Variable Engine and Variable Client Support for LabVIEW RT (both version 1.7.0) are already listed on my RT target when I look at the Software category in MAX.  Please let me know if those are the software items you were referring to, if I need any others installed, and if not why I cannot see any shared variables or their libraries using the DSM.

 

Thank you!

 

-Joe

0 Kudos
Message 9 of 18
(8,721 Views)

Do you have the System State Publisher software installed on the RT target? This is the component that I was referring to 

 

http://digital.ni.com/public.nsf/allkb/FA5C65FF5645FA5A862575D30029B6E4

 

Best Regards,

Casey

0 Kudos
Message 10 of 18
(8,715 Views)