LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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
0 Kudos
Message 1 of 9
(2,923 Views)
Do you have these same problems when running VIs on separate machines and autodeploying through the Development Environment? Is this purely a problem when programmatically deploying variables in executables?
 
Can you post an example VI that demonstrates the problems you are having so we can troubleshoot this directly?
Jarrod S.
National Instruments
0 Kudos
Message 2 of 9
(2,903 Views)
Aha!  My problem is that I was trying to use a shared variable to share data between two PCs.  Apparently this only works if the "server" is an RT target, and PC to PC sharing of Network-Published Shared Variables isn't supported, even in the new 8.0.1 patch.  If I want to share data being published by a shared variable on a PC, I need to connect to the "server" PC from another PC not through a shared variable but through a datasocket.  D'oh!
 
-Danny
 
0 Kudos
Message 3 of 9
(2,898 Views)

Hi guys

Am using a similar approch to share data, in my case i have an RT target and i want to use a shared variable which is deployed on a PC. To deploy the shared variable on the PC, am using the similar invoke method and deploying the variables. but in one of the PC the deployment is proper and in another the variables just does not deploy. both of the PC have labview runtime installed. in the RT system am using datasocket VI's to connect to the shared variable. can any one tell me what might be the problem.

Actually finally i want to deploy the variables on a server which is redundant and is in cluster. so i need to make the shared variables a cluster resourse does any one have any idea about this .

Thanks

Arun Kamath

0 Kudos
Message 4 of 9
(2,786 Views)
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

0 Kudos
Message 5 of 9
(2,770 Views)

The arcitecture mentioned by you is absolutely correct, the only difference being that one of the host is a server(windows 2003) with 2 nodes in redundancy and it has a cluster IP address. I belive that the PSP srevice is not able to bind to the cluster IP and is binding to each node's IP seperately. can u please tell me which is exactly the service required for the shared variables to run. If i make those service as cluster service and bind it to cluster IP, i belive shared variable should work.

Thanks

Arun

0 Kudos
Message 6 of 9
(2,768 Views)
Arun,

If the Real-Time target can talk to one host PC and not the other, the problem should lie in the host PC.  It sounds like the host PC that the Real-Time target is unable to connect to is the one that is running on Windows Server 2003.  LabVIEW isn't officially supported on the Windows Server 2003 operating systems, so we can't guarantee that all features will work the same in that environment.  Besides the difference in operating system and the redundancy you speak of, are there any other differences between the host PC that works and one that doesn't?

Thaison V
Applications Engineer
National Instruments
0 Kudos
Message 7 of 9
(2,752 Views)

Hi

There is no other difference between them other than that the server is a cluster and not a single CPU, the cluster machine has 2 CPU with each CPU having its own network card and IP address. but the cluster makes it look like only 1 IP address, and i want to bind the PSP protocol to this IP address. and not the individual IP for each CPU. I know this is no were related to labVIEW, but it would be helpful if any any ane can guide me about this.

Thanks

Arun

0 Kudos
Message 8 of 9
(2,746 Views)
Arun,

It sounds like there is this hardware difference with the dual CPU/1 IP address scheme, but are both machines running the Windows Server 2003 OS, or it only the cluster machine that is running this OS?  Again, if Windows Server 2003 is used, that will be another reason in addition to the cluster/redudancy hardware scheme that can be causing trouble.  Also, we may want try seeing if we can communicate via Shared Variables between this cluster machine and another PC instead of a Real-Time target just to see if the communication path works as expected.  The Shared Variable uses Logos as the underlying communication method, and the following KnowledgeBase discusses how to enable the right ports for communication via this method.  Let us know what you find.  Have a great day!

Thaison V
Applications Engineer
National Instruments

0 Kudos
Message 9 of 9
(2,735 Views)