Error 56 occurred at TCP Open Connection

[rolfk]

It's much more likely your internet setup. Wifi maybe?

[DBISI]

I had it isolated in a private network yesterday... with no internet or wifi.

[Kyle97330]

I have been using TCP in LabVIEW for years and not once have I gotten error 56 and the only possible diagnosis was LabVIEW just randomly deciding not to connect 1% of the time.

I think you really have two options here.

First one, just slap a band-aid on it.  Put it in a loop, set a much shorter timeout than standard on your connect attempt, and if it fails, just instantly start trying to reconnect until if fails 5 or 10 times in a row.

Second one, try to isolate the problem to something.  Try connecting from two different PCs.  Try a different network card or cable.  Try a different network switch, or no switch at all.  Try connecting to a different device on the same port.  Try disabling your firewall and antivirus.  If you really do think it's LabVIEW, do a quick install of Python or some other language and try connecting with that on your current PC.

[rolfk]

I can only echo Kyle's comments. I have never seen such errors as you describe, except when on an unstable network connection.

[DBISI]

Ok. I will keep poking at it. I've tried a lot of this already... It's a very peculiar and annoying bug, and I keep going back and forth on what it could be.

I do currently have the open in a loop of 3 tries, and each try I ping the IP. The device is there. It just wont connect.

I am going to take a second look to see if maybe I have a resource that failed to close issue.

[rolfk]

These boxes use typically a small CPU with some sort of embedded TCP/IP stack such as lwIP. They are resource constrained and depending on the used TCP/IP stack far less than perfect in comparison to your beefy Linux or Windows box. They may not even have any multithreading beyond very limited interrupts and often only a single CPU core.

If that controller decides to go into guru meditation to do some garbage collection of some sorts, only the low level interrupt driven IP layer with integrated ICMP handling may be still responsive but no higher level telnet on TCP/IP service.

Last but not least, from my own experience I trust the Windows sockets implementation (and the Linux of course) and the LabVIEW interface to it a lot more than any self brewed embedded hardware with heavily resource constrained hardware.

Even if you had this same problem with other Ethernet hardware in the same setup would be my first suspect rather a bad cable or switch than a bug in the LabVIEW TCP/IP layer. But if you can’t reproduce it with another hardware from a different brand and another software such as Python, the entire PC side is extremely unlikely to be the culprit.

That you can still ping the hardware proofs not a lot. It’s analogues to conclude that you can get somewhere by train because your friend could get there by car. The train may not ride while the car still can use a secondary road when the highway is closed. 😀