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

[Michel_Gauvin]

Hello,

I have a large scale application developped with LabVIEW DSC which deals with many computers on a LAN.  In one of the VI I'm opening shared variables connection using the "Datasocket Open" VI.  I have notice that after rebooting my computer and running this VI in source code (I haven't tried with a executable yet) that it takes approximatively 20 seconds to get a successful connection for one shared variable that is located on another computer.  The subsequent "Datasocket Open" calls for the same computer for the same shared variable takes much less time, approximatively 100ms.  I have reproduce this with 3 differents computer, so the behavior seems to be reproducible, but it's not doing it everytime but very often.  This scenario can also happen when I haven't open a connection to another computer for a while.

Does anyone have experience this? Is there something I can do about this to avoid this 20 seconds delay? Does anyone has an explaination?

All my computers runs Windows 8.1.  I'm using LabVIEW 2012.  All my firewall are "off".

Thanks,

Michel

Here's a picture of my open VI.

[Jacobson-ni]

Are you able to reproduce this behavior with a VI that just connects to a single shared variable with datasockets rather than your large application?  It will be much better to troubleshoot if we remove everything that isn't completely necessary to the issue at hand.

Also, are all of these computers on the same subnet?

[Michel_Gauvin]

Yes I think you should be able to reproduce this on a much smaller scale.  Create a library with one shared variable and deploy it on computer A, reboot computer B and try to open a connection to it.

Michel

[Jacobson-ni]

Did you read through this?

http://digital.ni.com/public.nsf/allkb/E57A771B0C2E17A186256F3800475628?OpenDocument

I'm not sure how helpful this will be because it's pretty old but it seems to explain the same problem you are experiencing.

[Michel_Gauvin]

I have check all my computers connection and none of them have a DNS configured.

[smithd]

They do have a DNS, it just might not be set by you. Matt is likely correct, its something to do with the lookup. When you connect using datasockets are you using an IP address or a computer name? An IP should be faster. When you encounter these long connection times are you doing *anything* else on those machines? Anything at all? Datasockets use activex and run in the UI thread, meaning that in some situations even doing things like opening the File menu can cause them to hang in horrible horrible ways.

That having been said, why are you using datasockets instead of the shared variable API? The variable API was purpose-built to talk to shared variables and doesn't have the hang problem.

[Michel_Gauvin]

Hello smithd,

I'm using computer name to connect, so you are right there must be DNS somewhere.  I'm not doing anything special when connecting (thanks for the insight of how the datasocket is working).

I will try with the shared variable API.  At first I didn't wanted to use this API because of the lack of a "timeout" parameter.  In our system sometime computers are "offline" and we don't want to spend time trying to open a connection to it.

Thanks,

[smithd · Accepted solution]

I recently made this for another customer. You can emulate a timeout (and actually connect faster) by using the 'open in background' function and then checking the variable.connected? property.

[Michel_Gauvin]

Hello smithd,

I made a few tests and it looks promissing.  I do have a few comments about the code you sent:

- It is assume that all the shared variables can be located on the network, because if not the function "To More Specific Class" will take 5 seconds to timeout, but it's better than 25 seconds in my case.

- With the Datasocket API the read function contains a input "Wait for updated value" value which is not available in the shared variable API (LabVIEW 2012). Let me know if I'm wrong here.  I've programmed my own for now.

I have a questions regarding the connection to the shared variable once it is open.

- Is there a way to set a timeout when reading values?

- What is the default timeout?

Where can we get more information on the shared variable API? I'm asking this because there are different type of refnum related to shared variable like "shared variable refnum", "sharedvariableIO".  In the DSC function palette there is a function to convert a string to a shared variable called "String To Shared Variable" but when I take the output of this function and put it into the input of "Open Variable Connection" I get the following dialog from the broken wire:

I know it's of different type but is there a reference manual on shared variable that explains in detail how they work and the different type...?

Thanks,

Michel

[smithd]

The long execution time on to-more-specifc shouldn't happen as far as I know. You may want to shoot an email over to the support guys and ask them to check for/generate a bug report. The refnum should know its a network variable and shouldn't do any other operations. Something you can do to get around this is just pass your variables in as an array of strings and remove the cast function (passing the strings straight into the open-in-background func). This should dodge that delay, and I believe the code already ignores errors.

There are special PSP-specific variables on a subpalette, including read-with-timeout:

http://zone.ni.com/reference/en-XX/help/371361L-01/lvcomm/pspvaraccess/

I don't know the default timeout.

The last piece is one of the bigger issues with DSC shared variables...there are two purple wires which are totally incompatible. I don't regularly use SVs but when I have, I've done the following:

• Use DSC's purple wire to configure the variables, including library creation and deployment (ie configuration)
• Use the variable API to access the variable's data once I get to my main processes (ie runtime)

As for the purple wires, they are both strings they just have different URL formats, delimiters, etc. So you can use the pattern match functions to replace / with \ and \\localhost\blah with ni.var.psp://, etc. I don't remember where it is, but I believe the DSC sample project in 2013 has a VI for converting between the types, but the pattern match isn't hard either.