04-04-2025 10:10 AM
It's much more likely your internet setup. Wifi maybe?
04-04-2025 10:31 AM
I had it isolated in a private network yesterday... with no internet or wifi.
04-04-2025 12:42 PM
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.
04-04-2025 01:02 PM
I can only echo Kyle's comments. I have never seen such errors as you describe, except when on an unstable network connection.
04-04-2025 01:57 PM - edited 04-04-2025 01:59 PM
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.
04-05-2025 05:18 AM - edited 04-05-2025 05:24 AM
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. 😀
04-07-2025 08:04 AM - edited 04-07-2025 08:05 AM
My gut feeling tells me its the Numato itself, getting hung up for a moment. I don't think it's my code. I don't think its the network. I don't think it's the cables. I have 5 PC's all failing to connect to the Numato at the same time.
There is no way to check the IP resource is available like you can with a VISA port, is there?
04-07-2025 08:36 AM
@DBISI wrote:
There is no way to check the IP resource is available like you can with a VISA port, is there?
Not sure what VISA function you mean. But the closest to what you ask is basically ping but as I explained, this is low level IP functionality and as you found already that still responds. To test higher level TCP communication, the only way is to attempt to connect to some port on which you know that the device is listening on. There isn't usually another supervisor on network devices that supervises that a specific port is still responsive, respectively if there was it would almost certainly simply try to connect to that port and fail in the same way.
I've been indirectly involved in a few projects where a Numato hardware was used. I don't remember this specific issue, but they were not the most trivial devices to deal with. Their telnet interface also isn't exactly plug and play but more plug and pray. We did some workarounds to get the communication more reliable. The LabVIEW examples they provided were definitely nothing to write home about.
04-07-2025 09:32 AM
That seems to be my experience with these as well. I appreciate the help anyway. I learned a bit on how this works. Thank you.
I will leave this open, for now.