Deploy Shared Variables

I'm having an issue with using SVE. I'm using LV 8.6 (cannot upgrade to 2010 at this time, have to "make it work").
I've used shared variables before with an HMI and PXI but my setup is different now:
PXI (called my target) that "talks" to different controllers via Modbus TCP/IP. Separate PC to interface to the PXI to provide a user-interface (called my host).
I've run across posts talking about calling the Deploy Library method in the top-level VI of the application. I want the PXI to deploy the shared variables since it will be running constantly and the PC is optional. Do I "manually" transfer the shared variable library, in this case called the NetworkVars, to the PXI so the PXI application can find it? The PXI will be running independently once the program is completely developed.
I've used Labview a long time but have never had to do much with networking/sharing.
Thanks for any help.
Solved!
Go to Solution.

I still cannot figure this out, have read NUMEROUS white papers, help entries, etc. but I cannot get it to work properly.
PXI system with analog I/O, TCP/IP connections to Watlow controllers. This is where I set up NI-PSP variables, autodeploy enabled, run as startup when I transfer the program to the PXI.
Separate computer running an interface program to the PXI, the front panel controls and indicators are "bound" to the PSP variables.
I download to the PXI, reboot it, start my PC program and there is no communication. The PSP LEDs on the bound items are all green but there is nothing going back and forth, UNLESS I run the PXI program on the other development computer.
I know I'm missing something simple, just getting a little aggravated! LabVIEW 8.6, no DSC module, just the RT module.

Similar Messages

Deploy Shared Variable Engine in localhost

I need to talk to multiple RTs using single computer. It seems
obvious to deploy shared variable engine (libraries) in localhost instead of
RT. However, the problem is the shared variables (read) used in localhost VIs
are not being updated from RTs. But when I am using another local VI to update
the shared variable, it is working just fine. The variable path of the RT looks
like "\\My Computer\Local NPSVlvlib\Test
Data". I think this is the problem why the values are not being updated
because RT cannot resolve the network path ("\\My
Computer\Local NPSVlvlib\Test Data"). Also, I tried to change the shared
variable path in RT but I could not do it. Help Needed!!!!
Solved!
Go to Solution.

Thanks for your reply. I found in this link http://zone.ni.com/devzone/cda/tut/p/id/9900#toc2 that host computer can host the shared variable library and RT does not need the shared variable engine. See below
If your application includes a single host computer and a single or multiple RT targets it is recommended to host the library on the host computer. This will save memory and processor time on the RT targets. Also, by hosting the library on the host computer instead of the RT target, you can reduce the software install footprint on the RT target. The RT target will not need the Network Variable Engine, but will still require Variable Client Support. The Network Variable Engine allows hosting, the Client allows communicating with libraries on other machines. You can see a RIO target with these installed in Figure 4.
That exactly what I am trying to do. Any comments?

Error -196736204 occurs when deploying shared variables?????

When I try to deploy shared variables contained in a library named 'DAQ_sv.lvlib' I get the following message for each shared variable in the library.
Deploying DAQ_sv.lvlib:exit \\192.168.1.100\DAQ_sv\exit deployment failed (error: -1967362041, IAK_SHARED: (Hex 0x8ABC7007) Out of range.).
this paticular message was generated by the shared variable 'exit'.
Does anyone know what caused this?

Hello Steve,
You probably have a shared variable in this library that has the "Bind to Source" option checked in its properties but the path for that binding is either incorrect or empty. Make sure all the variables in this library have valid bindings. Also try deploying a new library to new variables make sure that there is nothing else wrong.
Regards,
Chetan K
Application Engineering
National Instruments

Deploy shared variable on specific ip

Hi, there is the problem to deploy shared variable on a specific network interface. There are many network interfaces in my computer. If I wan to deploy the variable on the nework interface with the physical address 00:50:56:C0:00:01 and the ip 192.168.117.1 I followed this, but I get that: This is the wlan ip. What is wrong? use Labview 2012 SP1 32bit

What version of LabVIEW are you using? Are you deploying the Shared Variable with LabVIEW Project? Are you running LabVIEW Real-Time? Do you have a Remote declared in the Project? If so, simply put the Shared Variable Library (in Project Explorer) on the Remote and tell it to Deploy -- it should (automatically) go to the right place.
Note that the note you cite is from LabVIEW 8.2.1, which was one of the earliest implementations of Shared Variables. There have been many changes in the last 5-7 years ...
Bob Schor

Deploying shared variable

Is it possible to disable or hide the deploying shared variables dialog box at program start?

Hello Peter
No, it is not possible to completely disable or hide this dialog box when deploying a VI to a real time target or building an executable since this dialog box is used to report errors during the download process. The only thing you are able to do is check the Close on successful completion checkbox to close this dialog box after a successful download.
Carlos Pazos
Applications Engineer
National Instruments Mexico

Deploying Shared Variables to Remote Target?

I have a 2-application server/client setup where my client(s) merely read information "published" by the server via a Network-Shared Shared Variable. If I run my server on a "clean machine" (i.e. no LabVIEW development) and I "publish" the shared variable library (via the "Library : Deploy Library" Application method) to the localhost, I have no problems whatsoever reading the data in the client (the path of the .lvlib file provided to the Invoke Method VI is an absolute path to the .lvlib file, BTW). However, I'm having a bear of a time getting the server to deploy the library to a machine running a second client on the same network - to do this I still use the same absolute path to my .lvlib file for the first input to the method (it's in the same place on the target as well as on the host, not that I know what this means for a targeted host) and I specify the IP Address of the target machine on the second input. There is no firewall on either machine (I removed it because I was getting nowhere and needed to eliminate a possible source of problems) and my router doesn't filter traffic going across the local subnet. Am I not using the programmatic publishing correctly to publish to another target (from within the server), or can anyone point out any problems in my usage?
By the way, if I publish to the local host (127.0.0.1 or the host machine's IP address) I do not get an error out of the "Invoke Node" VI. However, when I try to publish to a network target (both machines have the Variable Manager running and both machines work fine if both server and client are on the same machine) I get error code 1 and the message: "Invoke Node in MyServer.vi<APPEND> Method Name: <b>Library : Deploy Library</b>" which is anything but helpful.
Any help would be greatly appreciated!
-Danny

Hi Arun,
I hope you're doing well. I'd like to clarify the architecture that you are actually using. It sounds like you are deploying a network-published shared variable library on two seperate host PCs. You are then attempting to read data from both of these hosts from a RT target using the Datasocket VIs. The RT target seems to be reading from the shared variables from one of the hosts just fine, but you can't read from the other host. Are both hosts deploying their libraries in an executable as mentioned in previous posts, or is the deployment process done through the LabVIEW development system? Also, when you connect to the hosts using Datasocket, how are you entering in the addresses for each item? Lastly, it might help to know whether you have LabVIEW and LabVIEW Real-Time versions 8.0 or 8.0.1. If you could provide some more information on your set up, we can try to give some suggestions. Thanks!
Thaison V
Applications Engineer
National Instruments

Error programmatically deploying shared variable lvlib from an installed app

I'm using shared variables in my app. According to what I've read, I need to deploy the lib programmatically using the app invoke node deploy library. I do this and it works fine for the app exe on my machine. But then I created an installer and tried it on a "virgin" machine and I get a "error 1 at invoke node" saying "an input parameter is invalid." I added an indicator that shows the lib file path I'm using and it's fine. I had left the target IP addr unwired but I also tried 127.0.0.1 just in case. Any ideas what's going wrong here?

Hi:
If including the SVE installer didn't resolve the issue then it looks like there are some other possibilities that are discussed in the following forum threads. Not sure if you've seen these yet, but hopefully they will help.
http://forums.ni.com/ni/board/message?board.id=170&message.id=240865
http://forums.ni.com/ni/board/message?board.id=170&message.id=230033
http://forums.ni.com/ni/board/message?board.id=170&message.id=249345
Message Edited by A Person on 03-23-2009 02:40 PM
Message Edited by A Person on 03-23-2009 02:40 PM
Alex Person
NI-RIO Product Support Engineer
National Instruments

Custom data type causing trouble in deploying shared variable to RT target

I seem to be having some difficulty in using a network published shared variable created from a custom data type when deployed as an executable on an RT cRIO target. I'll start by describing why I believe this is where the problem lies. I created my RT VI in the LabVIEW development environment (LV 2012) and everything works fine. This VI is pretty simple because it rapidly devolved in to a debug exercise. The RT VI starts by simply blinking the User LED a couple of times and then starts a simple acquisition loop to read a few values off the hardware using the scan engine (while still blinking the User LED). After reading the hardware, the values are bundled in to a cluster and written to a network-published shared variable defined by a type def custom control. The custom control contains five dbl precision floats. If it matters, the cRIO RT system hosts the shared variable in this case.
So, I deploy this under the development environment and everything works fine. The LED blinks merrily along, telling me that the program is running properly. Running a host VI that reads the network-published shared variable yields the desired result. All is good.
Now I want the cRIO system to run this simple program autonomously at startup. I build it, set it as the startup VI, deploy it and then restart the cRIO target. The LED never starts blinking... the VI does not seem to run. I will spare you most of the debugging work and jump to the end. I basically "Diagram Disabled" various sections of code until the VI started running correctly as an executable. I kept reducing the size of the disabled code until only one thing was disabled: the write to the custom data type shared variable.
So, I guess my question is this: Are custom data types defined by type def'd custom controls allowed in executable RT programs? I've read through the cRIO Developers Guide, my NI Real Time Development course book and the Using Shared Variables white paper and I didn't see anything that forbade it. I know that there are some things not allowed in executables that are allowed in the development environment (front panel property nodes, dialog VIs, OS-specific calls, etc), but no mention of custom data type shared variables. Any ideas as to why my VI runs in the development environment but fails when compiled unless I remove the write to the network published shared variable?
Thanks in advance for your help!!
Solved!
Go to Solution.

Paolo,
So I thought that you meant to disconnect them in the build specification. Under the Additional Exclusions in the build specification, there is a check box for Disconnect Type Defs. I checked that box, recompiled, redeployed and it did not work. At this point I had to give and move forward, so I was going to convert the data typed from a cluster to an array. When I went in to change the data type in the shared variable pop-up from the project explorer, there was a big button under the variable definition that "Disconnect from Type Def". Clicked that button, recompiled, redeployed, restarted and everything worked great. Thank You!!
I suspect that I'll have to be careful if I change the definition of that data type (add an element, etc) since it is no longer connected to the data type. We'll cross that bridge when we need to.
Thanks again

How to deploy Shared Variables with aliases (Project Variable), when some machines are offline?

Hi all,
I have a distributed application (PC + a few CompactRIOs). My PC contains variables that have aliasing enabled -- they are bound to variables on the cRIOs.
One of the cRIOs is currently offline. I'm trying to deploy some changes I've made on the PC side. Unfortunately, LabVIEW refuses to deploy my PC libraries, because it can't connect to the cRIO that the variables are bound to.
How can I bypass that check, and force my PC to update? (I don't see why it's compulsory for the cRIO to be online for this :-/)
Thanks in advance!
Solved!
Go to Solution.

Thanks for responding, Esteban!
To answer your questions:
No error codes. The deployment dialog just says, "Failed to connect to Real-Time target". That's expected, because the cRIO is not connected to the network.
I'm binding simple numeric types only.
The cRIO has been taken offline for maintenance. I'd like to update my PC .lvlib files, and test some modified PC code, but I can't because LabVIEW won't let me deploy my PC libraries or run the VIs if it can't find the cRIO. (Here's another common use case: I'm developing software before I've received my hardware, and would like to test my VIs without a cRIO connected)
I've attached a minimal example (LV 2012 SP1). I have a VI on the PC that plots data from the cRIO, and processes local data. I'm trying to run the PC VI when the cRIO is offline.
Expected outcome: The VI should run, and "PC Output" should change according to "PC Input". "cRIO Output" should have a default value, and the PSP LED should be red -- mousing over the LED should say "Bad Quality".
Actual outcome: LabVIEW refuses to run the VI completely, saying "Failed to connect to Real-Time target".
Attachments:
Project Vars.zip ‏10 KB

Deploy Shared Variables when Application Executes

This is an option in the Project build specification in LV2010. I am finding that the check mark to signify that I want to include a lvlib in the build and have it auto deploy will not stay check marked.
I have tried to make sure a NSV reference appears in the startup vi and also have tried to 'always include' the library file in the build. I have attached an image of the dialog in question. The checked box in the listbox will go away when I close the build window or if I do the build and then reopen the build spec. This seems like a bug. Any way around it?

Sachsm,
   Thank you for reporting this unexpected behavior. I have filed a Corrective Action Request #279570 with R&D to be fixed in a future version of LabVIEW.
   Unfortunately the only workaround for now is to only exercise this option right before building (i.e. do not close the window and reopen it to build) the application.
   Again thank you for bringing this to our attention.
Regards from Austin,
Ben J.
National Instruments
Applications Engineer

Shared Variable Deployment not accessible in Build Specification

Hi everyone,
I have a large project developed in LV 8.6.1 from which I executed numerous applications. I converted the project in LV 11 sp1f1, everything works well in code, everything is saved.
I wanted to build executable without cod change for LV 11 here is what I found:
Build the executable with Build Specifications inherited from LV 8.6 for which I checked on Use Labview 8.x file layout in Advanced. My application programmatically deploys all internal shared variables and when I wanted to access the Shared Variable Deployment in project in Build Specification then labview locked and I have to kill LV. Other time I did not access the Shared Variable Deployment and I start building executable when it looks the build progressing similar as in LV8.6 and last step before popping the attached error all the saved files in the build location were deleted.
I set up a build specification just for this LV 11. Again I wanted to access the Shared Variable Deployment and again labview is looping something from which I had to kill labview. I opened it again, I skipped the shared variable deployment line and I build the application. Because my application programmatically deploys shared variables I included in builder the lvlib where shared variables belong. The build files does not includes this time as output the file *.lvlib for which my inherited LV8.6 code programmatic deploys shared variables.
My question is should I change the code (very large code) taking out the programmatic variables deployment and to relay on the build executable to do deploy them then what should I do with Shared Variable Deployment line in Build Specification which for my large application is not accessible or is any way to still use the shared variable as in LV8.6 but for which I need *.lvlib in build location.
Another important issue: when I launched my application built as I showed in previous second case, first thing that I see is that my application is not able to save errors (I have a log file where I save different drivers or communication errors). Any idea why application even without shared variable deployed is not able to write a text file? I am administrator of my computer with all rights.
Thank you,
Virginia

No, I am not able to close Labview because of the windows error with only one button to close application. The application is correct executed. Next time when I start this project it is asking me if I want o recover even if I accept to recover it looks what I had last time it does not save.
For my application also I am building a VI without diagram built as source distribution for which I set in my builder this top vi and I excluded everything from the project because my application copies instances at the run time of this vi as many times as hardware modules I have in the system and also I have this vi included in my application (for the content of this vi). My vi contains interfaces for hardware configuration as well as drivers functions call for each hardware module I have to control in my application. Everything is good building this vi, but in less then one minute after the build is executed and build interface closes again I have the windows error which force me to close project. Next time when I open project I did not see the option to recover the project.
In the mean time I received second message and I wonder if you refer to files names or to folder names or all together. I checked and the maximum size is 122 characters in the vi paths.
Thank you,
Virginia

Shared Variable refuses to deploy correctly!

My problem seems like one that has been encountered before, but with no good answers on the NI documents or forums. When trying to run a VI that deploys shared variables, I keep getting an error that the shared variable engine cannot be found. This seems to be almost random, because I was able to deploy shared variables perfectly fine. It might have been when I restarted my computer that this problem started to occur.
I've tried disabling the firewall, that had no effect. LabVIEW 2009 reports the following when I try to run my VI:
"LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
This error or warning occurred while writing the following Shared Variable:
\\.\fake_data\flow_sh
\\.\fake_data\flow_sh"
I'll include all pertinent files so that you can see exactly what I'm doing. The purpose of the fake_data program is just to practice using shared variables, very simple. Thanks for any insight you can offer!
Solved!
Go to Solution.
Attachments:
fake_data.zip ‏145 KB

Is it possible you meant "net start ..." for the second command?
LabVIEW Champion . Do more with less code and in less time .

Shared variable engine with pro-face touchscreen windows 2000 professional

hello,
who has some experience with the shared variable engine from LabView 8.5 and a touchpanel from Pro-Face?
We try to deploy shared variables from the touchpanel but it doesn't work. Additionally the windows service ni shared variable engine dosn't start and we can't start it manually .
The touchpanel is a PS3701A from Pro-Face with Windows professional 2000 for embedded, Pro-Face told us that we have the full service of Windows 2000 professional on a regular PC.
Many thanks in advance
derN

Hi Andrew,
Thanks for the feedback! Your feedback will help us to improve LabVIEW for our customers. This bug has been reported to R&D (#45493) and they are currently investigating this issue. For now, the best workaround appears to be using a different OS, as this seems to only occur in Windows 2000. Thanks for the feedback!

Difference between Shared Variable Refnum and Control

Dabbing my toes in Shared Variables for another project. Glad to see A LOT more support from NI in terms of Shared Variables (especially now that built executables can be set to automatically deploy shared variable libraries...thats a big help).
In the Shared Variable block diagram palette (under Data Communication) there are a number of VIs that can be used to progmatically access and consume shared variables. Awesome. One thing that I have noticed is there is a difference between a "Shared Variable Control" (from the I/O front panel palette) and the "Shared Variable Refnum In" that you obtain from right-clicking one of the VIs from the Shared Variable palette and selected "Create Control".
My first thought was that these two were one and the same, but they are not. Visually they look different:
Also, the reference input to the VIs in the Shared Variable palette only take the "shared variable refnum" control as input. The control from the "I/O" palette does not work.
This wouldn't be much of a problem, but I prefer the look of the Silver Shared Variable Control much more to the control I get from the "Create->Control". Also, the variable browser in the Shared Variable Control is A LOT nicer than the control refnum gives me.
Here is the Shared Variable refnum variable browser:
Here is the much nicer looking browser that pops up from the Shared Variable Control:
So I guess my questions are:
Why are there two reference data types that seemingly perform the same function but are incompatible with one another in LabVIEW?
How can I use the Shared Variable Control with the Shared Variable palette VIs?
Thanks for your input.

Hello Nickerbocker,
You actually want to use the Shared Variable Control in the context of Alarms, I/O Servers and other categories inside the DSC Module. Like you already saw, to use the basic functionality of a Shared Variable, such as programmatically reading / writing to it, you need to use a refnum.
Regards,
Daniel REDS
RF Systems Engineer
Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.

Shared Variable

Hello all:
I developer a VI with OPC Shared Variable . It run good in my developer PC.
Then package it into setup programme， intall it to another new PC.
Run vi.exe. When deploying shared variable, i got an error.
my_opc.lvlib\\127.0.0.1\my_opc deployment failed(error: -1967362042, os and network serviceshex ox 8abc7006)
Attachments:
11223.JPG ‏33 KB

Hi,
This url may help you:
http://digital.ni.com/public.nsf/allkb/1F45A4298B976F4A86257168006EA0C3
Then, when you use SV communication, you have to check :
- the network settings of the PC,
- the runtime Labview or a development Labview installed on all PC.
I hope that it has solved the problem.
Best regards.
R. Kaszubiak

Deploy Shared Variables

Similar Messages

Maybe you are looking for