LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

lifespan of TCPIP connection Id

I have a VI that stores key-value pairs.  The Key is a string and the value is a TCPIP connection ID.  The array of Key/Values are stored in a shift register.

 

The second VI is a wrapper around TCPIP functions to provide Connect, Read, Write and Disconnect interfaces.  A unique device ID is passed to the VI.  When a connect is made, the  connection ID is stored in the key-value pair VI.  Subsequent callers are expected to pass the unique device name in, and lookup ocurrs for the connection ID.

 

The third VI uses the second VI as follows:  Creates a connection, and makes numerous calls to perform reads and writes.  Disconnect is never called.

 

No problems yet.

 

Now, after the third VI executes, a forth VI passes the same unique ID and attampts a write.  The code immediately fails with an error code of 1.  When debugging, the value stored in for the connection ID is correct in the shift register of the key-value VI.

 

I am wondering if when the third VI completes, LabVIEW is destroying the handle to the file descriptor.  Even though the value stored is correct, it is now a dangling reference.  I would not expect this to ocurr, becuase there is still a valid reference in the shift register.

 

If my assumption is correct, any ideas of how to resolve.  Or, any other thoughts?

 

Thank you,

Bruce

0 Kudos
Message 1 of 3
(2,774 Views)

Hi BAS99,

      It sounds like you've correctly diagnosed the problem!  When a VI terminates, LabVIEW will automatically deallocate the resources it has acquired - unless it remains part of an executing [higher-level] VI.  Assuming the Third VI is not part of a higher-level VI which keeps executing, then when it terminates, the connection references allocated by "the second VI" are cleaned-up - leaving you holding a useless reference#.

 

      The only solution I know of is to give "the second VI" a non-terminating "thread" of its own, that is, make it part of a diagram that never stops executing.  Create a "Host VI" which has a single event-structure waiting for a quit-button or some other event, and place the second VI on that diagram (calling some innocuous function.)  Startup the Host and leave it running.

 

For the record, LabVIEW does not clean-up ActiveX resources and I expect the same is true for .NET but I'm not sure. Smiley Wink )

 

Cheers!

 

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 2 of 3
(2,762 Views)

Just to make it clearer - a reference will be automatically closed when the top level VI in the hierarchy where it was originally created goes idle. A top level VI is either the one you press the run button in or one you call dynamically using the Run VI method. You can do this either by creating a daemon for managing the connections and calling it dynamically or placing the third and fourth VIs in the same caller, which will become the top level VI.


tbd wrote:

 

For the record, LabVIEW does not clean-up ActiveX resources and I expect the same is true for .NET but I'm not sure. Smiley Wink )


I believe that's not entirely accurate. I think that the difference is that LabVIEW can't automatically release .NET and AX references when the code runs (unlike VI server refs, so the TCP reference is actually similar in that way) and that it does do what it can when the code stops, but sometimes you need to explicitly close dispose methods to properly clean up. But I don't know of any official documentation regarding this beyond's Brian's blog and I just make sure to close every .NET and AX reference.


___________________
Try to take over the world!
0 Kudos
Message 3 of 3
(2,734 Views)