TCP error 62

[MaSta]

Hello! There were a few topics regarding this error and looked through them and actually none of had a solution or at least none for me. In one of the other thread a regular user meant like "perhaps Windows has closed the socket due to inactivity". I wouldn't know that Windows does that. And most of all, why?

We have used the TCP VIs in quite a few solution and never had this. What, in my case, might be different to what we did before: between opening the socket and sending the first message some seconds pass. As it seems, this is the reason. In the attached test VI when they delay is 0 - 4 seconds, it works as expected. With 5 seconds, either error 66 or 62 would come. 

Is this normal? Is this Windows or LabView? 

Windows has a connection timeout, but it's not rigid. Atm. I don't know how to determine it, but I don't think it's only 4 second. There is also a keep-alive timeout in  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, which is set to 30000 (presumably milliseconds). Another place to look at are the network adapter settings, but there are none regarding timeouts.

[GerdW · Accepted solution]

Hi MaSta,

most devices I worked with maintain their own "Keep TCP alive" timeout setting. Most often I configure them to "never timeout" (or "keep alive forever") when possible.

Example:

[MaSta]

Case closed. The remote socket (here: one of our products) would close the connection after a variable timeout. I know that and totally forgot. 

[rolfk]

While your answer explains the error you did I would actually consider Geert’s answer as much or more the solution as he pointed you correctly to the fact that this is a device specific issue. Why people first suspect LabVIEW or Windows to be the culprit rather than their device always amazes me!

If Windows was the problem it would be a firewall issue and those usually simply prevent connections, so the Open function would already timeout. LabVIEW itself does very little of these below the surface beyond what the actual function is required to do to work properly!

[MaSta]

Right. Now that you say that I realized that we wrote "device", not interface. 

The device would now be set up to not close the connection anymore, but then the next problem comes up. Error 1 from the TCP Write VI which isn't documented in the LabVIEW help.

The code in which error 1 occurs is split. One VI opens the socket and passes the handle to a sub VI. I verified that the handle has the same value once it arrives the sub VI and where it's used for TCP Write. There it would cause error 1. I counter-tested the same thing in Docklight where writing and reading ModBus RTU frames over Ethernet works fine. Then I turned the VI that turns off the timeout into a test VI to recreate the split where the handle is converted to variant and back. It still works fine. On the internet there is an explanation for error 1.

[rolfk]

Error 1 is very much documented: It is the argument error. For VIs with refnums it usually means that the passed in refnum isn’t valid (anymore).

[MaSta]

OK, well, it's not documented in the list of TCP errors I wanted to say.

Like I wrote, I verified that the handle number comes correctly out of the conversion and that the device doesn't close the connection anymore. Else it would be error 62. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000wziACAQ&l describes a possible reason, but I don't see that in my code happening. The handle goes into a variant which is part of a cluster and in the sub VI vice versa. I modified the test VI using the cluster now:

 --> this also works, but still not in the other code with the sub VI. The content of the ComRef cluster element doesn't change until the sub VI is called. The handle arrives, but if it's still valid or not - how to check?

[MaSta]

As an alternative to pass the "connection ID" to the cluster I now used a global variable. Same result, error 1.

    

[rolfk]

LabVIEW refnums handling through globals is ugly and facilitates one other problem. The lifetime of all LabVIEW refnums is managed by the lifetime of the top level VI in whose hierarchy the refnum was created. Once that top level VI goes idle all the refnums created in its hierarchy are auto closed! The NaN/Is Not a Refnum correctly indicates if a refnum is still valid. 

[cordm]

Here is an example of that. Start the Server, then Start Call. If you stall the data flow in Write, you will get error 1 during TCP Write.