Does anyone know of problems passing tcp network connection refnums to sub VIs in LabVIEW 7.1?

[Robert_Collins_(Heriot-Watt_University)]

I'm writing a program to collect some data across and send it across an ethernet network using the TCP routines in LabVIEW 7.1. To make the block diagram more easy to follow, I turned some of the more common routines into sub VIs, passing in and out the TCP networking connection refnum via a terminal wired to the appropriate control on the front panel. Now I find that the server and client applications sometimes drift out of synchronisation so that they both end up trying to read data at the same time and eventually timeout.

The fault is intermitent (sometimes the program works without errrors) and doesn't happen at all if integrate the sub VIs back into the main VI.

I can use the program as it stands but the block diagram is a nightmare. Does anyone now of any issues with sub VI and network connection refnums?

[Xu]

Hi Robert,
I guess the reason is not because of passing the refnums to sub VIs.
When you use sub VIs, the program may run a bit slower than integrating the sub VIs into the main VI.
Are sure you used some synchronization technique in your program, or it just rely on the speed of the Server and Client?
Thaks,
Xu

[Robert_Collins_(Heriot-Watt_University)]

Thanks for the idea Xu, but I'm not sure that's the problem. Both client and server work on sets of read/write pairs. I'm daisy-chaining the TCP connection refnum through each of the TCP Palette VIs ("TCP Read" etc) in sequence, although some are in sub VIs. I assume that the TCP routines don't return until after they finished sending or recieving from the network. What seems to be happening is that "TCP Write" in either the client or the server (it varies) is returning, having claimed it has written the data but the corresponding "TCP Read" in the other program never recieves anything. Eventualy this leads to both programs reading at the same time.

[Xu]

Your data written seemed to be delayed by LV's TCP connection.
The following links could be a help:
http://forums.ni.com/ni/board/message?board.id=170&message.id=97123
http://digital.ni.com/public.nsf/websearch/7EFCA5D83B59DFDC86256D60007F5839?OpenDocument
Good luck,
Xu

[dsavir]

Hi,

Did anyone solve this issue? I'm using Labview 8.2 and at some point my program goes out of sync. my program has a client and a server ( at the moment both are on the same computer). the client sends stuff to the server, waits for answer, sends more, reads answer. etc. When in debug mode everything works fine. When it's not in debug or highlight mode, at some point a TCPread times out.  I haven't tried removing subvi's because the block diagram will look terrible.

Does anyone have any ideas? Is there an option to listen for an answer on an existing connection? TCP listen creates a new connection.

Thanks a lot!

Danielle

[dsavir]

Hi,

I tried bringing all the subvi's into the main vi and it works now... still, does anyone have a more elegant solution?

Thanks,

Danielle

[Robert_Collins_(Heriot-Watt_University)]

I'm afraid not Danielle.  In the end I had to do the same as you and integrate the block diagrams from the sub-VIs into the main block diagram - resulting in a very complex program.

A later program I tried to develop used a pair of TCP/IP read and write instructions inside a FOR loop in both client and server to carry out an iterative process on a series of data blocks.  The same problem also appeared in this case, even though the TCP/IP functions were in the main block diagram and, unfortunately,  time constraints meant I had to abandon this program before I had fully isolated the cause.

One possible solution that was suggested to me by a colleague, but which I did not have time to test, was to build my own set of TCP/IP VIs  in C using CINs to integrate them with the rest of my program.  This would take a long time to test and debug properly but may save time in the future.  I'm not sure how practical that would be for your application though.

[dsavir]

Well, I'll have to live with a giant block diagram then... I don't have the time to implement TCP/IP in C (and I think that for my simple program it would be pointless anyway).

Thanks for the feedback!

Danielle

[rolfk]

---

@dsavir wrote:

Well, I'll have to live with a giant block diagram then... I don't have the time to implement TCP/IP in C (and I think that for my simple program it would be pointless anyway).

Thanks for the feedback!

---

I have developed quite serious LabVIEW applications in the past using TCP/IP both communicating in between LabVIEW applications as to other third party applications and I always got them working reliable.

TCP/IP is however a bit special in certain ways in comparison to other LabVIEW functions. Due to the nature of the communication happening you can't just use the error cluster without some consideration (but certainly can't leave it out at all as that will create domino errors in your communication too). I have found that timeout errors in the TCP/IP function are usually not so much a real error as much more just an indication that the remote side had some timing problem and that retrying in such cases often helps.

Also in order to get a robust client server communication you have to sometimes build a certain restart architecture in place. For instance a timeout would mean retry at first and if still error, close the connection and reopen. Sometimes in dynamic networks I have found the nodes refreshing the TCP/IP address and that left TCP/IP connections in a strange state. Reads always returned timeout, writes worked ok but the data never got transmitted. Closing and reopening the connection on such errors made it work again. Or using static IP addresses seemed to solve it too. Of course such a restart operation also requires at both sides proper detection of the "connection closed by peer" error and according reopen it there too.

Your giant diagram is likely not going to be a permanent solution as small changes to your diagram might change the timing and cause suddenly problems.

Rolf Kalbermatter

Message Edited by rolfk on 02-05-2007 02:33 PM

[mattypiper]

rolfk,

Can you post an image or VI of an example of this robust TCP/IP communication you are describing?  You have a very good understanding of the nature of TCP/IP comm and I'm sure this lesson learned could be used in other comm protocols as well.   \

I am interested to see an example of the error-handling architecture you have implemented.  The scenario "Timeout, Retry, Timeout again, Close connection, Open connection, Retry, Success"  is probably very common and a great way of dealing with undetermined network latency.

Cheers,
--Matt