network shared variables lose binding

[TDRboy]

Hello,

I am developing an application in LabVIEW that uses network shared variables to transmit data between two PC's on the same subnet. The shared variables work fine when running the VI's in development mode, however, when i build the vi's into an executable I find that they no longer work. Here is what I have found so far:

I deploy the shared variable library on the publisher machine (also happens to be the development machine) through an invoke node in the executable. NI distributed system manager confirms that this does deploy and indeed updates as it should.

For the executable on the subscriber PC I created a second shared variable library (same project) with the same shared variables and bound them to the respective shared variables from the first library by selecting enable aliasing, then bind to PSP URL and browsing to the shared variable I wish to bind it to (e.g. \\hallnet-ellm2\shared variable library\serial Number). The machines listed under browse were listed by name so when I tried this initially and it did not work I manually changed the name of my machine in the URL box to the IP address of the publisher hoping that would fix it in case the subscriber could not resolve the publishers machine alias. So now my bind URL read \\192.168.0.1\shared variable library\serial Number.

As part of the executable on the subscriber I deploy this second shared variable library. NI distributed system manager confirms that this deploys but under quality for an individual variable it has a list of issues (see attached) and the bound variable is not updating. At this point the publisher shared variables are still functioning fine. By clicking on 'edit variable' I can see that the variable on the subscriber is still bound but the PSP URL is now \\localhost\shared variable library\serial number. Changing the PSP URL on the subscriber to \\192.168.0.1\shared variable library\serial number enables the variable to update as expected.However by this time my executable has already picked up the error and does not function.

I think that the issue lies with the bind URL used on the subscriber as for some reason it does not keep the binding configured in the project and instead changes to 'localhost'. Why is this? Should it not stay bound to the address specified in the project?

I have tried changing the IP addresses in the aliases file so that

[My Computer]
My Computer=localhost 

becomes

[My Computer]
My Computer=ip of local machine

This did not help.

The shared variable libraries are included in the build spec to go into the support files directory and they are successfully deployed from there on both publisher and subscriber.

I am using LabVIEW 8.6 on Windows XP

Thanks for any help you may be able to offer,

Lee

[Prashant M]

Hi Lee,

I hope you are well.  Thank you for your post.  Your application sounds very interesting.

Looking at your issue I was wondering, have you tried lowering your firewalls, as this may be causing the problem.

Also, another option would be to setup a private network.  Do you have access to any routers that you could use to link the two machines independent of your IT's infrastructure?

The other thing to try is two other computers entirely.  Again, it would be ideal to take them off the network you are on, but it's something to try if my prior suggestion doesn't work.  It should work on the original two machines though, and it's likely that different computers won't solve your problems because I suspect the network.

Remember that the client variables must know the location of the variables on the server, so you can't move the server exe around without changing this value.

Make sure to set the network location in the "Bind to Source" option for the client variables.

It is also possible to write a separate piece of code to install on every machine that is responsible for deploying the library and by doing so eliminate the need for programmatically deploying the variables in the original application.  However, this won't really help you, because the variables you use in the application have to be the same as the ones deployed in the library, so if you change the library, they'll no longer be linked and they won't receive data.  You'd have to create a separate exe for every binding source you wanted to link to, and then have a second, known library for the sake of communication locally on the computer between the ‘deployer’ and the actual application.  The main application could then be assigned the responsibility of launching the correct ‘deployer’' if it sees it needs to switch to a different variable binding source.  This method is not the most streamlined or effective, but it might work.

Just to let you know, you will need to use the DSC toolkit.

Please find below some knowledge base links that I think you will find helpful in your application.

Using Shared Variables in Executables

How do I Programmatically Change the Data Binding Source for Shared Variables?

I hope this information helps and if you can give these suggestions a go and let me know how you get on, that would be great.

Kind regards,

Prashant M
Applications Engineer
NI UK & Ireland

 

[TDRboy]

Hi Prashant M,

Thank you for getting back to me.

Some things I forgot to mention in the first post are:

The computers are connected through a switch and they have manually assigned IP addresses and the same subnet mask. Firewalls are turned off and I have even tried disabling the other network adapters on both machines incase these interfere with the setup. As the application runs in development mode would i be right in assuming that this is not a firewall issue?

The server exe remains on the development machine, the client exe is the one that I place on alternative machines.

I believe the issue lies with setting the 'Bind to Source' location option for the network variables as it is this that changes when deployed on the client machine. I have attached a zip file of an example project. I create the variables and then for the client variable i select ' Enable Aliasing' then i select 'PSP URL' from the drop down menu then I browse to the variable I want it to be bound to. Is this the correct method?

 I build the exe and then distribute the folder to the subscriber computer, when i run this (publisher already delployed and running) i get error 1950679023 for the shared variable on the client. I then load up NI distributed System manager and click on the shared variable deployed locally and see the error as shown on the picture attachment of first post.  If i right click on it and select 'edit variable'in the 'bind to' box  the location has changed to \\localhost\ rather than the publisher machine that was intended (and configuredf in the project on the publisher machine). If this did not change then i do not think there would be a problem. Is this expected behaviour?

It might be good if you could try and build and run the executables I created for the test project attached to see if you see the same behaviour? It may be that I have a setting wrong somewhere.

If all else fails then i may well have to try the programatically bind shared variables article you attached.

Many Thanks,

Lee

[Prashant M]

Hi Lee,

Sorry for the delay in responding.  I have come across another post that I think will help with your application. 

Shared Variable Error -1950679023 in LabVIEW 8.6.1

If you can try the steps this post gives and also try installing the patch found at the following link, this may help resolve your issue.

"This is an update for only LabVIEW 8.6.1 to fix an issue where the bound variable path is incorrect ...

I hope this helps and please, do let us know how you get on.

Kind regards,

Prashant M
Applications Engineer
NI UK & Ireland

[TDRboy]

Hi Prashant,

Thank you for the link to the forum. I am not sure that this applies to me as I am using LabVIEW version 8.6 not 8.6.1 and the knowledge base you linked states that it is not necessary for LabVIEW 8.6.

Please could you advise if it should help anyway?

Did you manage to reproduce the behaviour at all?

Thanks,

Lee

[Prashant M]

Hi Lee,

I hope you are well.  I have been looking into your issue and have managed to run the project that you sent me.  When I first ran your exe’s I saw the error (-1950679023) so I deleted your builds and created my own setting up the properties and the file paths, as in the attached images.

I then checked, using the Distrubted System Manager (LabVIEW>>Tools>>DSM) the functionality of the application.  Do your libraries with the shared variables appear?  If not, I would suggest deploying them from the project by right-clicking on them and selecting deploy.  Please remember to refresh the screen when you do this.

Once this was done I was able to run the exe’s fine, provided publisher was started before subscriber.

I hope this helps and if you can let us know how you get on, that would be great.

Kind regards,

Prashant M
Applications Engineer
NI UK & Ireland

Message Edited by Prashant M on 05-08-2009 10:59 AM

[TDRboy]

Hello Prashant,

The images you attached do not show the file paths for the libraries. Are they included in the support directory as they were in my builds? From what i can see of your builds they look identical to mine.

As an executable is compiled to run with the run-time engine there is no project on the subscriber computer to deploy the variables fromanywa, however, as i have said before, the problem I am seeing is not with the deployment of the shared variables as I have confirmed that they are deploying with the Distributed System Manager on both computers. The problem is with the bindings associated with the subscriber library. In library settings on publisher PC, before the build is created, the subscriber binding settings read bind to '\\hallnet-ellm2\publisher library\on server'. 

After the build is created and executed on the subscriber computer, looking in DSM reveals that the binding settings have changed to '\\localhost\publisher library\on server'. Manually changing this in the DSM on the subscriber computer to '\\hallnet-ellm2\publisher library\on server' allows the variable to bind correctly.

If the bind settings did not change on the subscriber when deployed this would not be a problem. And as a deployed system would ideally work automatically without the need to change settings in the DSM I am wondering why these bind settings that i originally set in the project manage to change once built and then deployed on another computer? Is there a setting in the build specifications that i have missed? Or is there a setting in the aliases file that i need to change?

Many Thanks,

Lee

[Prashant M]

Hi Lee, 

Thanks for the information. 

From what you have said please could you send me a screen shot of your shared variable properties configuration, highlighting the variable option as I am keen to see how this has been configured. I have tried to replicate the behavior that you are seeing and I have also informed our colleagues in the US about this as this is indeed some very unexpected behavior. 

As soon as I have more information, I will get back to you, but in the meantime, I have come across the following discussion forum that may be of use to you which suggests that you may need to disable your firewall.

Deploying Network Shared Variables From a Compiled Executable    

As soon as I have any further information from my findings I will let you know. 

Kind regards,

Prashant M
Applications Engineer
NI UK & Ireland 

Message Edited by Prashant M on 05-12-2009 01:48 PM

[Mark M]

Hello Lee,

Would you like to try this KB: When I Deploy My Application Why Do My Shared Variables No Longer Work?

I hope this helps,

[_Sven_]

Hi,

I got the same problem as Lee described.

The deployment of the shared variables works fine if I run the VI in development mode. If the VI/application is build as an executable the variable deployment doesn't work correctly.

In DSM I can see, that the shared variables are bind to the correct source in development mode (ipaddres of the source). But if the executable is used the shared variables are bind to "localhost" an not to the ip address configured and used in development mode.

Unfortunately the last link of Mark M is not more active so I can not have a look at the informations/solution.

Best regards,

Sven