LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Not connecting to some shared variables

Hello, I'm having a strange case of my VI connecting to some shared variables, but not to others from the same library. The attached code snippet shows the BD. All SV refnums are sent to the auto-indexing loop, where "Open and Verify Variable Connection" is executed for each SV in turn. A test indicator before the loop shows that all SV refnums are correct. However, the refnum array indicator after the loop only has some of the SV, not all of them (the missing SV names are just empty strings). At the first empty string the Error Out becomes "-1950678943:  Open and Verify Variable Connection in States.lvclass: prepareSV.vi". The DSM shows that all SV are deployed. Why would "Open and Verify Variable Connection" complete successfully for some SVs, and not for others? I could not find any difference between them in the DSM. Any suggestions would be greatly appreciated!

Download All
0 Kudos
Message 1 of 12
(3,897 Views)

Hi, could you give more information about the set up you have running in terms of hardware and software?

0 Kudos
Message 2 of 12
(3,862 Views)

There is no particular hardware -- LabVIEW 14 running on Windows 7. Everything runs and is deployed on the same computer.

0 Kudos
Message 3 of 12
(3,851 Views)

Have you checked the timeout of the variables? 

 

http://zone.ni.com/reference/en-XX/help/371361P-01/lvcomm/veropenvarcon/

 

Maybe if you take it out, the shared variables will open when they can. The error is due to a timeout when opening them, so I think it is a good step to try. 

0 Kudos
Message 4 of 12
(3,842 Views)

I did try long timeouts (as long as 10 seconds) without success. I didn't know I can remove timeouts completely, will try that shortly. Thanks for the suggestions.

0 Kudos
Message 5 of 12
(3,838 Views)

So I did some tests with the timeouts. Removing timeouts completely (i.e. wiring -1) results in the VI running forever, and never progressing past the Open and Verify Connection. Putting short timeouts (less than 45 ms) results in none of the SVs being connected to. Anything over 45 ms gives the same results -- successfully connects to some SV, but not to others from the same library.

0 Kudos
Message 6 of 12
(3,826 Views)

Hello,

 

Are there any differences between the shared variables that are connecting and the ones that aren't?

Niki Budgell | Product Planner - SW Management | NI
0 Kudos
Message 7 of 12
(3,802 Views)

That seems to be the $1000 question --  the only difference I see in the DSM is that most (but not all) of the SVs I can't connect to are in alarm as soon as they are deployed. I was planning on researching this. The same set of variables is deployed on another machine (and my VI connects to them fine), so there must be something that cause them to be in alarm and/or not allowing connections, that still escapes me.

0 Kudos
Message 8 of 12
(3,798 Views)

Have you set any alarms for the Shared Variables or can we see the alarm configurations?

 

Niki Budgell | Product Planner - SW Management | NI
0 Kudos
Message 9 of 12
(3,789 Views)

Hello Niki B, I think that might be at least partially related. Most (but not ALL!) of the SVs I cannot connect to are in alarm -- I'm still trying to understand why. They are all Boolean with initial values set to false. I though that could be the reason, but  when I removed "Set Initial Value" and re-deployed them, they're still in alarm, and unreachable. So that seemed to have been a red herring.

 

Yes, they all have alarming set.

0 Kudos
Message 10 of 12
(3,787 Views)