TCP: No Response after 1-5 min

[mtb999]

The setup:

I have two Windows XP computers sharing data through TCP, a client (C) and server (S). S listens on a port and C connects, which has the OK signal on the error wire. C writes about 32 bytes every minute or so to S in a while loop.

The problem:

After 1-5 minutes the data transfer stops, but the connection is still open. The program seems to stall after the TCP Write command on C's VI. If I physically walk over to the server and click on the VI, the TCP Write occurs and everything works!

I've tried setting the process priority for LabVIEW (in Task Manager) to higher, but it doesn't resolve the issue.

Does anyone have an idea of what is going on? 

[mtb999]

Since there have been no responses, I'll try to clarify.

The problem is that my TCP connection between two VIs stalls during a TCP write (the timeout is set to -1). If I physically go over to the other VI and click somewhere on the LabVIEW program, such as on the window title or the front panel, the TCP write occurs and everything works.

This is a problem because I have to walk over to the other computer to make the network write work ... when I want to have remote control!

???

[MikeS81]

Hi mtb999,

do you use something inside your vi which needs a user reaction? Can you show your code?

Mike

[mtb999]

The server VI is simple: it stalls at the TCP read shown.

The client VI, which is writing the command to the server, is a bit more complicated, but basically the subVI labelled "2" does the TCP write. The connection is sustained in the while loop, and doesn't open and close each time and read/write is performed. 

(The subVI with the checkmark verifies that the input is suitable).

Message Edited by mtb999 on 06-16-2009 12:01 PM

[MikeS81]

Hi mtb999,

which value do you really send over tcp/ip? is it a double value as it looks like in your image? In this case the "bytes to read" is to small.

Mike

[mtb999]

It isn't shown in those images of the block diagram, but the double is converted into a 7-character string. Then, the bytes to read is set to 7.

Any other ideas? The problem persists, and we have to click on the server's window periodically to make the server finish the TCP read.

[MikeS81]

Hi mtb999,

can you upload your vi`s? Can you reproduce this behavior on another pc?

Mike

[CoastalMaineBird]

but the double is converted into a 7-character string. Then, the bytes to read is set to 7.

I wouldn't do that if I were you.

If you FLATTEN the double to a string, then it's always eight bytes, and you know to read eight bytes and unflatten it at the receiving end.

If you CONVERT it to a string, it won't always be 7 bytes. 

Message Edited by CoastalMaineBird on 08-16-2009 06:02 AM

[CoastalMaineBird]

If I physically go over to the other VI and click somewhere on the LabVIEW program, such as on the window title or the front panel, the TCP write occurs and everything works.

THAT is the weird part.  There's no mechanism I know of to react to a click on the title bar, from within LabVIEW.

However, is your receiving computer set to sleep after a time?

It sounds like the computer is going to sleep, thinking it's not being used.  A click anywhere wakes it up.