Jump to content
Sharon_

TCP/IP error code 66

Recommended Posts

Hi friends,

I am developing an application where I need to send modbus commands thru' TCP/IP, to a mastercontroller. But , sometimes I am getting the following error and I dont know how to figure it out. Because it happens sporadically.frusty.gif

I checked the VI server and the settings seem to be ok. throwpc.gif

Could you please help me??

Thanks for your time..!!! worshippy.gif

post-16569-0-30918100-1295414250_thumb.p

Sharon

Share this post


Link to post
Share on other sites

Hi Sharon

from here TCP/IP Error Codes

====================

There are two typical error codes in cases where TCP/IP communication fails as a result of a timeout condition:

  • Error 56 is generated when an operation exceeds the user-specified time limit. This error is caused by the LabVIEW code not receiving a network response in the defined time limit.
  • Error 66 occurs if the TCP/IP connection is closed by the peer. In this case, Windows notices that no data is returned within a reasonable time, and it closes the TCP/IP connection. When LabVIEW attempts to communicate after Windows closes the connection, error 66 is the result.

In a Windows environment, either error 56 or error 66 are possible. However, without determinism it is not possible to specify which communication error will occur first. If Windows polls to see if a connection is valid and subsequently closes the connection before the LabVIEW TCP/IP VI times out, then error 66 will result. However, if LabVIEW detects that no response is received before Windows has a chance to poll the connection, error 56 will be generated. The unpredictable timing associated with when each of these operations times out and which one occurs first results in different error codes being generated by different runs of the same VI.

=======================

We do a lot of testing over TCP/IP we get these error sometimes for a number of reasons, our UUT has reset, we have opened a new TCP/IP connection without closing an old one to the same UUT, plus many others.

In our TCP/IP driver library we look for and trap both error 56 & error 66, we then clear out the error and depending on our TCP/IP target we may try to close the existing connection and then simply reconnect or maybe we will close and ping to ensure target is back before we open a new connection.

For specific advice you will need to give more details of what you are doing and maybe post an example code.

cheers

Dannyt

Share this post


Link to post
Share on other sites

In a Windows environment, either error 56 or error 66 are possible. However, without determinism it is not possible to specify which communication error will occur first. If Windows polls to see if a connection is valid and subsequently closes the connection before the LabVIEW TCP/IP VI times out, then error 66 will result. However, if LabVIEW detects that no response is received before Windows has a chance to poll the connection, error 56 will be generated. The unpredictable timing associated with when each of these operations times out and which one occurs first results in different error codes being generated by different runs of the same VI.

=======================

In the space of one paragraph you have explained about a decade’s worth of random mysterious TCP/IP errors!

So when the error uses the term "peer", is that referring to the TCP/IP connection on the local machine? That error description makes it sound like the remote machine was actively closing the connection.

Share this post


Link to post
Share on other sites

In the space of one paragraph you have explained about a decade’s worth of random mysterious TCP/IP errors!

So when the error uses the term "peer", is that referring to the TCP/IP connection on the local machine? That error description makes it sound like the remote machine was actively closing the connection.

Correct.

"It did not hear you talking so it hung up."

Ben

Share this post


Link to post
Share on other sites

If you Google for

connection closed by peer

you will find this is the standard description for this error for lots of programming APIs. For example

http://technet.microsoft.com/en-us/library/cc957018.aspx

This is one of those cases where LV described the behavior using industry standard terms, which is sometimes a "damned if you do, damned if you don't" situation... very helpful for those who know the networking standards and are working in LV, somewhat misleading for LabVIEW programmers working with networking standards.

Share this post


Link to post
Share on other sites

If you Google for

connection closed by peer

you will find this is the standard description for this error for lots of programming APIs. For example

http://technet.micro...y/cc957018.aspx

This is one of those cases where LV described the behavior using industry standard terms, which is sometimes a "damned if you do, damned if you don't" situation... very helpful for those who know the networking standards and are working in LV, somewhat misleading for LabVIEW programmers working with networking standards.

If only we had a "ping" function wink.gif

  • Like 2

Share this post


Link to post
Share on other sites

Hi friends,

Thank you very much for your replies. The problem was with the network card. I replaced the card with a brand new one and it worked. But I am still not sure how it affected my application. Anyway it is a lesson learnt.

Thank you..!!!worshippy.gif

Sharon

Share this post


Link to post
Share on other sites

Hi all,

I am getting the same error if I wait for say t(approx 10 sec)> sec. But I checked the time out with 100s and 180 sec. There is no effect of the value settings. Attached VI if for your ref.

Apart from the VI I am using only 'TCP Open Connection' function. Do I need to change any network config of my PC?

Thanks for your time..!!!

LAVAG.zip

Sharon

Share this post


Link to post
Share on other sites

Here's a potential hack to retry the connection if you get an error. If you create a LV2 style global / action engine to store your TCP/IP connection info, you can place that VI inside your MB query and reset the connection if you get an error 66 or 56 or whatever.

post-549-0-21084900-1296143335_thumb.png

post-549-0-41775000-1296143370_thumb.png

post-549-0-61816200-1296143379_thumb.png

post-549-0-20064300-1296143389_thumb.png

I can't compile it down to 7.1 but included in the zip file as 8.6 if someone else can down convert it.

TCP Connection LV2.zip

Share this post


Link to post
Share on other sites

Here's a potential hack to retry the connection if you get an error. If you create a LV2 style global / action engine to store your TCP/IP connection info, you can place that VI inside your MB query and reset the connection if you get an error 66 or 56 or whatever.

post-549-0-21084900-1296143335_thumb.png

post-549-0-41775000-1296143370_thumb.png

post-549-0-61816200-1296143379_thumb.png

post-549-0-20064300-1296143389_thumb.png

I can't compile it down to 7.1 but included in the zip file as 8.6 if someone else can down convert it.

Hi bbean,

Your VI just works great. Thank you very much for sharing it with us.worshippy.gif

-Sharon

Share this post


Link to post
Share on other sites
Hi all,

I am getting the same error if I wait for say t(approx 10 sec)> sec. But I checked the time out with 100s and 180 sec. There is no effect of the value settings. Attached VI if for your ref.

Apart from the VI I am using only 'TCP Open Connection' function. Do I need to change any network config of my PC?

Thanks for your time..!!!

attachicon.gifLAVAG.zip

Sharon

 

You can't dismiss the device itself. Some device may have an internal timout to free up resources which means they will actively and willfully drop any connection that has not seen any data transmission for a certain amount of time. While your desktop computer has a sea of memory and CPU power to process many parallel TCP/IP streams at the same time, your embedded device is typically much more resource constrained. They may not even be able to serve more than one endpoint at the same time, so any host trying to connect to them and leaving a connection hanging could block the device for anyone else entirely. That may be a security feature, by locking out other network access while you do some sort of transaction on the device that needs to be uninterrupted by anyone else, but if the device would allow infinite time for a connection to stay open, any misbehaving application could block the device totally for anyone else.

 

So check your documentation! Most likely there is some info as to how long a data connection can stay open inactive before the device will close it from its own side, which is in fact the most common reason for error 66. Another possible reason for this error could be that the device detects some errors while serving the connection, either misformed data packets or some network protocol error due to for instance your bad network card or noisy connection and simply drops a connection on any such error.

 

It is the safest thing to do in network communication: If there is any error during processing of the network connection, close it immediately and let the client reconnect. Your client software should be able to cope with that by using the information returned in the error cluster. Generally a robust network client would treat error 56 as an indication to retry the last operation one or more times (but not indefinitely) and if the error 56 persists or any other error occures, close the connection and attempt to reopen it.

  • Like 2

Share this post


Link to post
Share on other sites

Had the same problem guys. Spent about a week to find a solution. Implemented ways to restart TCP connection, as described before.

Finally called to support NI. Support engineer recomended to check the network properties.

The broblem was as follows: my microcontroller (MC) and operator machine (PC) were in defferent subnets.  As subnet was tuned to simmiliar fo both MC and PC, the error 66 has varnished, as the problem did.

Good luck. Take care of yourself.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.