TCP/IP error code 66

[Sharon_]

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.

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

Could you please help me??

Thanks for your time..!!!

Sharon

[dannyt]

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

[Grampa_of_Oliva_n_Eden]

Most of the times I have seen that error it was traced back to an over-loaded CPU on the server side.

Edit

by "that error" I am talking about intermitant error code 66.

Ben

Edited January 19, 2011 by neBulus

[EricLarsen]

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.

[Grampa_of_Oliva_n_Eden]

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

[Aristos Queue]

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.

[ShaunR]

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

[Sharon_]

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..!!!

Sharon

[Sharon_]

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

[bbean]

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.

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

[Sharon_]

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.

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.

-Sharon

[FixedWire]

Just by adding the constant "immediate" to the TCP Read function fixed the issue here!

 

 

[Rolf Kalbermatter]

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

 

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.

[FixedWire]

Thank you Rolf. Good insight as always!

[VadimB]

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.

[Ehsan Rezaei]

I have the Error-66 as well. Please comment on that:

https://drive.google.com/file/d/19j5cTGmy6FOMEWNH7U_uiZtUzcV8De4i/view?usp=sharing

[Rolf Kalbermatter]

On 8/13/2021 at 8:26 PM, Ehsan Rezaei said:

I have the Error-66 as well. Please comment on that:

https://drive.google.com/file/d/19j5cTGmy6FOMEWNH7U_uiZtUzcV8De4i/view?usp=sharing

Sorry but with some me too message and an image we can't do much. Have you read the comments in this thread? Have you studied them and tried to apply them to your situation? What debugging steps have you done so far? What is your hardware configuration including network setup?

You really will have to do the debugging yourself. There is no such thing as a free lunch when debugging your own application!

Edited August 15, 2021 by Rolf Kalbermatter

[Ehsan Rezaei]

Thanks for your reply, Rolf.

The code is written with an undergrad in our lab about 7 years ago. I have no knowledge or experience of LabVIEW.

I just performed some experiments with the machine, and suddenly got the ERROR-66 from nowhere. 

Best,

Ehsan

[Rolf Kalbermatter]

3 minutes ago, Ehsan Rezaei said:

Thanks for your reply, Rolf.

The code is written with an undergrad in our lab about 7 years ago. I have no knowledge or experience of LabVIEW.

I just performed some experiments with the machine, and suddenly got the ERROR-66 from nowhere. 

Best,

Ehsan

That's not enough information to say anything specific. Error 66 simply means that the remote side decided to close the connection. That could be for many reasons such as:

- Bad network setup that causes dropouts

- DHCP configuration that causes a change of the network address so that the connection is not valid anymore and gets reset by the remote side

- subnet address configuration mismatches

- another network device trying to grab the network address used by either side of your current connection

and a few dozen more possible problems including bad hardware in your computer, the remote device or some network infrastructure in between

[Ehsan Rezaei]

Main-vi.tifHi Rolf,

The IT department check my PC and FPGA network connection and they confirmed that all good from that side. They said the error is becasue of the PC-FPGA connection. 

However the code worked well for a couple of months, I think now one of my PC or FPGA are slow, so they cannot shake hands, and consequently the code assumes that as "peer closed connection". I have added all the diagram on my Main.vi. Please tell me what would be the first step of debugging the code?Main-Main.tif 

Main-vi.tif Main-Try_to_Connect.tif Main-Idle.tif Main-Initialization.tif Main-StopConnection.tif

Edited August 17, 2021 by Ehsan Rezaei

[Rolf Kalbermatter]

16 hours ago, Ehsan Rezaei said:

Main-vi.tifHi Rolf,

The IT department check my PC and FPGA network connection and they confirmed that all good from that side. They said the error is becasue of the PC-FPGA connection. 

However the code worked well for a couple of months, I think now one of my PC or FPGA are slow, so they cannot shake hands, and consequently the code assumes that as "peer closed connection". I have added all the diagram on my Main.vi. Please tell me what would be the first step of debugging the code?Main-Main.tif 

Main-vi.tif 908.46 kB · 1 download Main-Try_to_Connect.tif 431.32 kB · 0 downloads Main-Idle.tif 300.02 kB · 0 downloads Main-Initialization.tif 356.04 kB · 0 downloads Main-StopConnection.tif 363.26 kB · 0 downloads

Debugging pictures is unfortunately not possible. And without the hardware I couldn't really do much either. I can not comment to the tests your IT department did, but they likely understand even less of the problem than you do and can only do some standard tests that may or may not point out the problem.

There is a lot of information in this thread about things to check. I can't really give more ideas. You will have to read through everything and test it on your system to see if you get any results. Debugging network problems is a highly specialized ability that requires to understand a lot of different things, often a lot of time, and the hardware at hand to go through the many tests and trials to hopefully end up with some indications where the problem could be and then find the solution for it. And yes it is hard. Networking has been getting ubiquitous to the point that everybody simply expects it to be present and working. In reality the techniques involved are highly complex and even simple misconfigurations can make it fail. TCP/IP with its many fall back and fail save mechanisms makes this sometimes even more complex, since it doesn't just fail flat out but still sort of works, but with much degraded performance.

[FantasticNerd]

On 8/17/2021 at 9:56 PM, Ehsan Rezaei said:

However the code worked well for a couple of months

So normally I would start thinking about what had changed in the whole environment so that it will not work anymore.

Were there an IT Firewall update?? Some Anti-Virus Software Updates? Have you or someone else changed the code? The hardware? The connection? Normally an Application does not behave different if nothing changes.

 

[Tim_S]

2 hours ago, FantasticNerd said:

So normally I would start thinking about what had changed in the whole environment so that it will not work anymore.

Were there an IT Firewall update?? Some Anti-Virus Software Updates? Have you or someone else changed the code? The hardware? The connection? Normally an Application does not behave different if nothing changes.

 

Don't forget versions, updates and patches, particularly in operating systems. For example... had a customer call me with a station that was down after a couple years of running. It looked like a UDP communication issue between two PCs. Wireshark showed the UDP message showing up at the port, but the application didn't receive it. Eventually this was tracked down to the build of Windows 7 (1609, if I recall right) can randomly turn off a setting that UDP needed to work. The "fix" involved a registry edit, but it's waiting to happen again.

[Ehsan Rezaei]

Thank you guys for your useful points. We have Windows 7 and we do not update that. I did not change anything on the code or device. 

The only issue before the error happening is that I obviously can see a time lag of about 3 seconds on my signals. It means, when I trige the device, in my HEKA Patchmaster software i can see the Time-Displacement signal of the piezoelectric actuator, but the same thing will show up in my LabVIEW after 3 seconds. When this delays build up on eachother then I get error-66.

 

Main.vi_ScreenShot.tif

[Tim_S]

I take it you don't have a dedicated connection between the two devices. Things that can break the system that come to mind is the routing and if there are duplicate IP addresses on the network.