Using LabVIEW 6i w Win NT or 95/98 et al: how do you keep a TCP/IP open connection 'open'. The application closes the connection even though the refnum is still active (valid.)

[tom raper]

Actually, I open the TCP/IP connection and pass the connection ID through. Each command to/from (cycle) the UUT successfully executes. The refnum for the connection ID is then passed via a shift register in the while loop. i am using the type cast (4X) function to determine the validity of the connection and case statements. If the refnum is non-zero it assumes the connection is still open; if the result is zero, then the connection is closed and a new session opened in that case. What is happening is that the connection has closed and the refnum is still nonzero after the type cast function; su
bsequent commands to the UUT then produce Error 1 for the TCP/IP function (there was no open connection, so there could be no write occurrence.) Obviously, this probably shouldn't be happening. If someone can give me some idea of what I am not doing, or am doing wrong, I sure would appreciate it. In the event that I open and close a connection for each command to(from)(cycle) the UUT everything works. It is extremely slow. The connection should remain open according to all the pointers in the Help and TCP/IP function descriptions. Some of this application is proprietary, so not sure how much of an example I could use to illustrate from a VI, but if this doesn't get any where, I will see what i can do to better illustrate the problem...Thanks. T.Raper

[Christopher Mitchell]

I don't think a non-zero TCP refnum is a good test in determining whether or not the connection is still open. I loaded the 'Simple Data Server/Client" example VI's that come with LabVIEW. I modified them so that they displayed the refnum (using the Type Cast function) after the connection was closed. Everytime I ran the VI and then stopped it, I got a non-zero value for the refnum. I also got a 62 or 66 error code.

The following webpage shows how to handle multiple connections. I don't know if this will help or not.

http://zone.ni.com/devzone/conceptd.nsf/webmain/DF1A54455AA43C9786256802007B8D79?OpenDocument

[tom raper]

Well, yes it helps and obviously I have to agree that the non-zero refnum was not working. Hence, the question. Problematically, examples for client/server don't seem to be the answer either. What happens on this link is the setup for the command/response to the DUT. What is observed in the application is that the connection does in fact close without actually using the TCP/IP Close function. It is peculiar in that, depending on the command executed, it is observed to remain open only as long as the command is actively processed repeatedly, for example, as a status check of a DUT activity in a loop. Once the loop is exited, the link is closed,and no new command is processed and error is generated upon the next write. Even this does not always keep the connection link open; it is somewhat random in that event.

What I attempted to do in pricipal was use the session refnum created in th Open connection to validate the next operation. The refnum is returned as if the session reamined open, when it has in fact closed. I have a serial port monitor in HyperTerminal to look at all the traffic to and from the DUT as data is processed through the command inteface. Typically after the response from the DUT is received, we see the connection close. We have created application in C++ and JAVA also and do not see this occur. In those instances the connection remains open indefinitely.

The problem with setting up a listener is that the application initiates the communication and therefore there is nothing there to listen for, producing an error.

I will attempt to reconstruct this using the queue as illustrated. It is possible that the open connection can be validated in that manner. However, part of the relative speed issue, may also pop up here. If it takes X number of CPU instruction cycles to monitor the connection, query the queue, produce an error if the connection is closed and then close the previous connection and/or open a new connection...then that may take more time and bandwidth than simply opening and closing the connection each time a command is issued to the DUT -which does work.

Thanks for the advice, though, I will let you know if I have any luck with it.

[JeanPierre]

Tom,
You can test for a valid TCP connection using the comparison function "Not a Number/Path/Refnum". It will return TRUE when the TCP session is closed. The refnum DO NOT reset to 0 when the connection is closed.
A TCP connection is automatically closed by LabVIEW when the VI hierarchy under which it has been opened terminates. Thus you can't reuse a connection after your VIs has stopped or pass the refnum from one hierarchy of VIs to the other if the creating hierarchy stops.
So make sure that the hierarchy (Top Level VI) under which the connection is opened stays running as long as the connection is required.

[tom raper]

This looks like the right answer. Have to try this. Knew there had to be something I was missing. This would explain why the connection remains open while in a scan loop as commented on against earlier answer. Let me give this a shot and will get back to you with results at that point. From above it looks as if most likely will continue to use open/close as new commands are processed, but should speed things up for loops, scans, and such, especially for relatively large data dumps. Really appreciate the help!

[tom raper]

Comment #2. Yes, correct method. Also correct that the connection is closed as stated. The problem remains that this appplication is large, 50 Megabytes or more, and consists of multitudes of sub-VI's that the connection closing automatically precludes using an 'ever open' connection in LabVIEW. Even opening the connection at the top level loop (where applicable) does not produce the desired outcome. It is conceivable that this may help with some of the larger data driven loops, but not very useful for most of the command/response to/from the DUT. Since the open/close functionality works, although somewahat slow, it will suffice for now. It would be nice to see a future release of LabVIEW handle this open connection as a defacto state unless closed, or clo
sed by time out or loss of connection, wherein the "Not a Number/..." would be the check method for closing existing and opening a new connection as required. Thanks, however, and we will post a solution when we find one.

[Greg_McKaskle2]

> Comment #2. Yes, correct method. Also correct that the connection is
> closed as stated. The problem remains that this appplication is large,
> 50 Megabytes or more, and consists of multitudes of sub-VI's that the
> connection closing automatically precludes using an 'ever open'
> connection in LabVIEW. Even opening the connection at the top level
> loop (where applicable) does not produce the desired outcome. It is
> conceivable that this may help with some of the larger data driven
> loops, but not very useful for most of the command/response to/from
> the DUT. Since the open/close functionality works, although somewahat
> slow, it will suffice for now. It would be nice to see a future
> release of LabVIEW handle this open connection as a
defacto state
> unless closed, or closed by time out or loss of connection, wherein
> the "Not a Number/..." would be the check method for closing existing
> and opening a new connection as required. Thanks, however, and we will
> post a solution when we find one.
>

It sounds like you are wanting to keep the tcp connections open and be
able to pass them between VIs in the application that are at least at
times dynamically loaded. As mentioned earlier, when a VI in LV
finishes execution, its resources get closed, provided LV knows about
them. This works much the way the OS does for executables, but as you
note, there are times when you rather not have this going on.

What I'd recommend is to make a wrapper VI for Open and Close. These
VIs will access a collection of refnums, but will arrange for another VI
that you keep running as long as you like to allocate and return the
refnum. In otherwords, build yourself a vendor of tcp refnums. You can
give them names, numbers or
whatever you like in order to allow sharing,
store them in a global array, and then have some accessors to act as the
open and close.

Greg McKaskle

[tom raper]

I tried a similar method using Globals and what I found was that the refnums were constanly changing, only rarely did a TCP session open repeat itself and then not more than once. Not sure exactly how to implement your suggestion or if it is essentially differecnt from what I have tried. To open a number of connections at once, store in global array, and use the "Not a number/...ref num,etc." to find a valid open session and then close all in array when no opens are valid, and reopen, reload array, and so on? Or something else entirely?

What I am really looking for here is speeding up the execution. The DUT command process (VI) is embedded in the heirarchy of the main program and each of the sub VI's as sub VI's of the command VI's. S
o not sure how to implement your suggestion at moment. Studying it. Any other information/clarification is appreciated.

[Mike Seibel]

I believe this is a related question. I am developing a LV application the uses TCP/IP to control up to 8 devices-under-test (DUT) at one time. They start and finish testing at arbitrary times relative to each other, and the IP addresses are not known until the DUT arrives. I have some question on what is the best way to manage the TCP/IP handles.

Presently, I have 8 Global IP addresses (one per testing site) that are updated as DUTs arrive and depart, and then whenever I need to communicate with a DUT I use TCP-Open, Write/Read, and TCP-Close. I do this Open/Write/Close each time there is a message to be sent to a DUT. This is basically working, but I notice that the OS (Windows XP or 2000) is running through local TCP/IP ports at a ferocious rate due to the TIME_WAIT behavior of Closed TCP/IP ports (It takes many minutes for a local port to become available again after being closed). If I am not careful, I can quickly exhaust the pool of OS ports by using tight polling loops or other very quick DUT accesses. I have tried not to do that in order to avoid running out of handles, but it is still very wasteful of ports.

While it is working, I feel so dirty burning through these handles like this since they appear to be a precious resource. I really cannot easily merge multiple Read/Writes into a single Open/Close since there are dozens of otherwise unrelated tests that communicate with the DUT as a part of their functionality. The tests are even in different subVI's that are accessed via a vi-server, and only one is loaded at a time.  

I thought that a cute idea would be to cache the handles in Globals, and wrap the Open to use the cache if valid, but reading this thread is making me think it is a lot of effort -- I believe I would need to keep a VI running as a "IP Connection Server" at all times and use some form of messaging to get it to Open/Close TCP connections as needed. Since the DUTs arrive at aribitrary times, and with random IP addresses, I cannot establish all the TCP handles ahead of time -- they would need to be created dynamically. It is much more difficult than simply keeping the Connection IDs in global variables -- the VI that Opened them must not be allowed to terminate.

So... I am curious...... is it really that bad to Open/Close as frequently as I am doing it? Does it make me a bad person? I understand it is inefficient use of time, but the simplicity it brings to the structure seems huge, and the DUT is very slow anyway. And if it is bad, are they any more recent thoughts on alternatives? Do VISA handles behave the same way as TCP handles (ie. auto-close themselves upon exit of the VI that Opened them) ?

Message Edited by Mike Seibel on 11-28-2005 07:55 PM

Message Edited by Mike Seibel on 11-28-2005 08:00 PM

Message Edited by Mike Seibel on 11-28-2005 08:01 PM