LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why it takes so long to open a connection to a shared variable the first time?

Solved!
Go to solution

Hello smithd,

 

Yes the "to-more-specific" can be bypass.

 

Thanks for the discussion, I will mark this discussion as solution since it has greatly improve my timing issue.

 

I will update to LabVIEW 2014 in the next week with DSC and will perform some tests.  Based on my results I will get back to NI if I need more features.

 

Thanks,

 

Michel

0 Kudos
Message 11 of 12
(494 Views)

Hello smithd,

 

I've been doing some digging into this.  I found out that only one computer had the behavior describe in the fist message.  In fact it was due to a dns problem.  That specific computer is physically connected to my router and is also connected with wifi to the same router.  The physical connection was configured on the computer to be "static" with and IP address unreachable by other computer on the LAN.

 

For some reason, after a period of time my router is changing the dns lookup to match the address of the "static" IP.  I found this out by using the following command:

 

nslookup computername

 

And it was returning the configured "static" ip address unreachable by other computer on LAN.  This probably why the "DatasocketOpen.vi" took more than 20 seconds the first call, and I had a error with the Shared Variable API (this is why I made more digging).

 

I have removed the "static" IP and put it DHCP, and the problem went away (I made several tests).

 

This being said, I will still use the Shared Variable API because the "DatasocketOpen.vi" is unstable like you said in previous post (I've got many errors from this function while clicking on the menu and GUI of my application, errors which I don't get when using the Shared Variable API).

 

Thanks,

 

Michel

0 Kudos
Message 12 of 12
(478 Views)