LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why should you explicitly open and close shared variable connections?

I'm looking into switching over from the old Datasocket API to the new Shared Variable API for programmatic access to shared variables, and I noticed that LV doesn't seem to have any problems executing Shared Variable Reads & Writes without first opening the connection explicitly. That is, I can just drop in a shared varaible Read VI, wire a constant to the refnum input, and it will work. I'm wondering, then, what benefits are offered by explicitly opening the conenction ahead of time...?

 

Open SV Connection.png

 

I guess I could see some cases where you want to open all necessary connections in an initialization state of a top-level state machine, particularly if you want to use the "Open & Verify Connection"---so you could jump straight to an error case if any connections fail. But other than that, why else might one want to explicitly open the connections.

 

And, along those lines, are there any problems with implicitly opening the connections? One reason why I am hesitant to open them explicitly is because for one of our applications, we need to be able to dynamically switch from one variable to another at runtime. It would be nice to just switch the variable refnum (wired to the input of the Read function), without having to manually close out the old connection and open a new one. A quick prototype of this seems to work. But am I shooting myself in the foot by doing so?

 

Thanks in advance.

Message 1 of 6
(3,586 Views)

Hi TurboPhil,

 

There are a couple of reasons why explicitly opening and closing the connections is the preferred method, besides what you already mentioned:

 

  1. When you are reading in a loop like in your example, opening the connection implicitly will cause the first read to take longer than the others. Opening in advance lets you choose when in your program you take the time to open the connection, and makes it clearer in the code to see when that happens.
  2. Using the implicit method, my understanding is that the connection won't be closed until you exit LabVIEW. Each time you switch the variable refnum, you'll be opening a new connection without closing the old one. Depending on your application and how many shared variables you're using, that may not be a problem. The explicit method is more scalable, however, so it's good to use it when you can.

 

Morgan S

Applications Engineer

National Instruments

0 Kudos
Message 2 of 6
(3,557 Views)

I'd like to know more about Morgan's response, because I find that juggling a bunch of connection wires is far less scalable than allowing implicit connection management at the app level. It was Morgan's impression that what he said was true, but can we get a reply from someone at NI who knows for sure?

 

Additionally...

 

I see that a "connection" (purple wire) is just a string referencing the variable by URL. Does LV allocate some kind of session in memory using that string as a lookup? Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"? And what resources does this "connection" actually represent? Is it holding a TCP socket open under the LogosXT layer, such that we might eventually use up all the sockets exposed by the OS? Or does it only represent a handful of bytes on the heap for a session?

 

Basically, I'd like some amount of certainty about what resources I'm wasting or leaking, and where jitter in the read/write operations is introduced, when I choose not to explicitly manage "connections".

0 Kudos
Message 3 of 6
(3,064 Views)

I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for.  But, let's try to extrapolate from this rather old post to see if we can understand what they're forming their impression on.

 

The shared variable has to have some sort of reference going on in the background.  It looks like they're calling this a connection.  It's how LabVIEW knows where to find this variable on the network.  We can also see this reference certainly exists if we're opening/closing the reference in the explicit method.  You see the connection as just a string referencing the variable by URL.  This "reference" has to be stored somewhere.  No matter how we're looking at this, we're aware there's a reference of some sort stored. 

 

Now, we'd want to look at what would cause this reference to go away.  If you open/close explicitly, it's easy to see it goes away at the close.  If it's implicit, when would it make sense to close it out?  The VI can't be expected to guess where it's done being referenced and close it out.  This puts us into a situation where the soonest it could close is when the VI ends.  From my experience, references tend to be wiped when you close out LabVIEW.  It's this kind of idea that makes the FGV possible.  I wouldn't be surprised by Morgan's claim here.

 

If we look at scalability, you're talking about two different topics.  You're talking about adding an extra open, close, read, etc rather than just a few wires.  That certainly would look a mess.  In terms of the dynamic swap that was being discussed, we wouldn't be adding all of those.  The concern would be if enough connections were opened it'd start to behave similar to a memory leak.  This could be something that works with a smaller number of variables.  If you continue to scale, it becomes problematic.  This is why they suggest it's not scalable. 

 

To your questions:
Does LV allocate some kind of session in memory using that string as a lookup?

It would HAVE to allocate some memory to hold that string.  Otherwise, it'd be pointless to even have the reference. 

 

Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"?

I would expect this to be "it depends."  With the implicit method, I would expect it to open a new reference in each point it isn't wired.  This is similar to int x,y = 5;  x and y share the same value but are their own unique memory location.  If you wire the reference to the other points, it should use the same reference.  This would make more sense to me than the program seeking out any other potential usage of the variable in the application to see if there's already a reference open.  I could be wrong, though.

 

And what resources does this "connection" actually represent?

At best, this is just the string.  At worst, it's the string and the TCP socket.  I'd lean towards the first.  Opening and closing sockets should be relatively easy in most applications.  But, it also wouldn't surprise me if it holds the socket.

 

I'm sure others have a better understanding than I do.  But, that's what I'd expect for anything you've asked.

 

 

0 Kudos
Message 4 of 6
(3,047 Views)

You might want to look at the Help for "Use Shared Variables Effectively (Real-Time Module)".  Among other things, it discusses the notion of "stale" Shared Variables ("old" data left over from the last time the Variable was used).  It might shed some insight into your question.

 

Bob Schor

0 Kudos
Message 5 of 6
(3,037 Views)

@natasftw wrote:

I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for.  But, let's try to extrapolate...


I realy hope you're wrong about that. Shared Variables are a huge feature that required a lot of people to create, and they ride on a networking layer (LogosXT) that's used in several other core features of LV. It would take some serious churn at NI to rid the company of everyone in R&D who understand these technologies. To that end, extrapolating or inferring how this stuff works only serves to muddy the waters. I'd much rather hear it from the horse's mouth.

0 Kudos
Message 6 of 6
(2,994 Views)