Error -1950679023 on Network Shared Variable(s)

[_Y_]

Hi,

I got a customer project utilizing multiple Shared Variables. The code has with many hard-coded features related to the local network. Now I need to run the top-level VI in my local computer that is not part of the same network (Yes, I know, this would not be an error-free run but good enough for development purpose).

However, Error -1950679023 is launched immediately saying

The IP belongs to my computer. Seems, SW understands that “My Computer” and this IP point to the same machine. It identifies the shared variable correctly. But still launches the error.

This is configuration of the shared variable in BD.

This is configuration in the project. Note that this IP does not belong to my computer or my network.

It belongs to customer’s local network, but it does not belong to machine where the project is running. Anyway, the error message does not mention this IP.

Please advice how can I solve the problem. Rewriting property of the shared variable would be highly undesirable because: a) The code should be runnable in original customer computers; b) There are too many such shared variables to rewrite.

Thank you

PS: I run LabVIEW 2021 but the code was created with LabVIEW 2018.

[N.H. · Accepted solution]

Hi,

I have read your post thoroughly and the issue stems from one thing:
Even though the error mentions that the variable wasn't found on "your computer", there is no other location for it to look for the variable (since the variable exists on your client's PC).

To put it simply, a shared variable needs to exist on your network, but in your case the shared variable exists on your client's PC (which is not connected to your network). 
More details about shared variables can be found in this link, refer to it if you need more clarification:
Using the LabVIEW Shared Variable - NI

The best solution in this case would be for you to change the IP-s of the shared variables so that they would be present on your network.

I hope this helps.

Cheers.

[_Y_]

Thank you N.H.

I already read the page describing use of Shared Variables but did not catch that the variable can deployed and be discoverable in the computer without being published in the net. You clarified it for me.

If redefining IP for every variable is the only way, I have a problem. There are too many such variables in the project.

Is there a way to use scripting for this task? In this case I could walk through the project altering IP for each Network Variable and saving original values in file. Prior sending the code to  customer I could do reverse setting.

[N.H.]

Changing the IPs through script isn't doable I'm afraid. But, there are 2 things that come to mind.

1. you could make a copy of the project, change the IPs, update the code as needed, and once done, copy the changes onto the customer's (original) project. You'd bypass having to change the IPs in the future, but you'll have to update the customer's project manually after finalizing it on your copy. Makes your life easier on a long-term basis if you'll have to work on the project often in the future.

2. I like this solution better: See if the customer would let you work on the project remotely. This would give you access to the project on the client's PC (also giving you access to their network).

I know these might not be the solutions you were looking for, I'd be looking for an out too if I were in your position. I really do hope this helps you work it out.

[_Y_]

Hi N.H.

I found a way for mass-changing IP. The solution is called "notepad":)) Shared Variable LVLIB is editable text file.

These are details for those who would probably meet the same problem. Replacing remote host IP with “localhost” or local IP does not help. Probably, variables must be deployed in remote machine. Is it so?

I removed three properties from description of each problematic variable: "Network:AccessType", "Network:ProjectBinding", and "Network:URL". Then changed value for property "Network:UseBinding" to False.

Seems, now the edited Shared Variables are deployed in local computer. At least, I can start the program.

---

@N.H. wrote:

2. I like this solution better: See if the customer would let you work on the project remotely. This would give you access to the project on the client's PC (also giving you access to their network).

---

Yes it could be good if... Current version of the program is in use. This includes equipment. So most of development tests must be done offline.

I mark your first post as solution. If someone needs more details he would read the whole discussion:))

[JÞB]

---

@_Y_ wrote:

Hi N.H.

I found a way for mass-changing IP. The solution is called "notepad":)) Shared Variable LVLIB is editable text file.

---

Yup, notepad is a handy tool for updating projects.

There is probably also a *.ini file for the SVE in the application support folder you can edit without even bothering LVAppBuilder.  HINT: don't tell the client that unless you code in a restore default from hidden location feature.

[_Y_]

---

@JÞB wrote:

---

There is probably also a *.ini file for the SVE in the application support folder you can edit without even bothering LVAppBuilder.

---

Interesting, thank you. Is it so for compiled EXE only? There is no one INI file in the customer file structure and the customer runs program without compiling executable.

[JÞB]

---

@_Y_ wrote:

---

@JÞB wrote:

---

There is probably also a *.ini file for the SVE in the application support folder you can edit without even 

---

customer file structure and the customer runs program without compiling executable. 

bad idea.  Don't trust customers with source code!

There is no one INI file in the customer file structure....

no, in the IDE it's saved as part of an xml file with a .lvproj extension, as you have found out..  NI DAQmx stuff is treated similarly and the app builder creates <Support>\NI DAQ\DAQmx.ini.  I don't use Shared Variables much but suspect <support>\NISVE\ or similar would exist to populate SVE settings from the lvproj to the executable.

[_Y_]

Thank you @JÞB

Now I understand.

---

@JÞB wrote:

---

Don't trust customers with source code!

---

Well. At least in half of my project customers trust me with their code😉