TCP connection lost and unable to restart

[GuentherS]

Dear all

I have a puzzling problem with TCP connection

I have 4 HV power supplies connected which are ueried regularly for voltage and current

All instruments have a fixed IP adress and are connected via a USB-ethernet adapter to a WIN11 PC

This works fine for a while but then the connection is lost - error 66

Then I close the connection and try to re-open, but this does not work

Here an excerpt from the logfile. with a good section for reference

22.07.25 08:13:27,810 TCPIP::192.168.6.1::2101::SOCKET >M1 ?   -- query current

22.07.25 08:13:27,937 TCPIP::192.168.6.1::2101::SOCKET Read M1:+9.77859E-05\013\010
22.07.25 08:13:27,937 TCPIP::192.168.6.1::2101::SOCKET >M0 ?   -- query voltage

22.07.25 08:13:28,068 TCPIP::192.168.6.1::2101::SOCKET Read M0:+6.49968E+02\013\010
22.07.25 08:13:28,068 TCPIP::192.168.6.1::2101::SOCKET >DVR ?  -- check if compliance is reached

22.07.25 08:13:28,178 TCPIP::192.168.6.1::2101::SOCKET Read DVR:1\013\010
22.07.25 08:13:29,180 TCPIP::192.168.6.1::2101::SOCKET >M1 ?

22.07.25 08:13:29,280 TCPIP::192.168.6.1::2101::SOCKET Read
22.07.25 08:13:29,280 TCPIP::192.168.6.1::2101::SOCKET Instr read Error: 66, TCP Read in Instrument_Read.vi
22.07.25 08:13:29,480 TCPIP::192.168.6.1::2101::SOCKET Instr close
22.07.25 08:13:29,480 TCPIP::192.168.6.1::2101::SOCKET Instr open Timeout 3000 Endstring LF
22.07.25 08:13:32,480 TCPIP::192.168.6.1::2101::SOCKET Instr open Error: 56, TCP Open Connection in Instrument_Open.vi
22.07.25 08:13:32,784 TCPIP::192.168.6.1::2101::SOCKET Instr close
22.07.25 08:13:32,784 TCPIP::192.168.6.1::2101::SOCKET Instr close Error: 1, TCP Close Connection in Instrument_Close.vi-
22.07.25 08:13:32,784 TCPIP::192.168.6.1::2101::SOCKET Instr open Timeout 3000 Endstring LF
22.07.25 08:13:35,785 TCPIP::192.168.6.1::2101::SOCKET Instr open Error: 56, TCP Open Connection in Instrument_Open.vi
22.07.25 08:13:36,087 TCPIP::192.168.6.1::2101::SOCKET Instr close
22.07.25 08:13:36,087 TCPIP::192.168.6.1::2101::SOCKET Instr close Error: 1, TCP Close Connection in Instrument_Close.vi
22.07.25 08:13:36,087 TCPIP::192.168.6.1::2101::SOCKET Instr open Timeout 3000 Endstring LF
22.07.25 08:13:39,086 TCPIP::192.168.6.1::2101::SOCKET Instr open Error: 56, TCP Open Connection in Instrument_Open.vi
22.07.25 08:13:39,387 TCPIP::192.168.6.1::2101::SOCKET Instr close
22.07.25 08:13:39,387 TCPIP::192.168.6.1::2101::SOCKET Instr close Error: 1, TCP Close Connection in Instrument_Close.vi
22.07.25 08:13:39,387 TCPIP::192.168.6.1::2101::SOCKET Instr open Timeout 3000 Endstring LF

When I close my Labview EXE and restart it, everything is fine again, but after minutes or few hours the error returns

The error affects all 4 instruments connected at the same time, so I guess the problem is on the PC side rather the instruments

The waiting times between TCP commands are already at 1sec, so this should not be the problem

In the power setting we made sure the USB-ethernet adapter cannot be turned off

Firewall exception for the used port 2101 is in place

Any ideas?

Thanks

Guenther

[Bob_Schor]

Have you tried running your code with only one power supply?  If that works, do you get interference with two?

A suggestion -- consider using a TimeStamp format that includes seconds instead of thousandths of minutes -- makes it much easier to see that the commands are at least a second (or ,016 minutes).

Bob Schor

[raphschru]

Hi Guenther,

Error 66 for TCP is when the connection was closed by the peer (the power supply in your case):

https://lavag.org/topic/13678-tcpip-error-code-66/

I see in your log timing that you send a new request as soon as you get the answer from the previous request.

You may overload the power supply's CPU with too frequent requests, which is why it may decide to close the connection by itself.

Try waiting like 100ms between a read and the next write.

The power supply user manual may even specify a minimum time to wait between successive commands/requests.

---

@Bob_Schor wrote:

A suggestion -- consider using a TimeStamp format that includes seconds instead of thousandths of minutes -- makes it much easier to see that the commands are at least a second (or ,016 minutes).

---

The format seems perfectly valid: %d.%m.%y %H:%M:%S%3u with a comma as decimal separator for seconds.

Regards,

Raphaël.

[Bob_Schor]

---

@raphschru wrote:

---

@Bob_Schor wrote:

A suggestion -- consider using a TimeStamp format that includes seconds instead of thousandths of minutes -- makes it much easier to see that the commands are at least a second (or ,016 minutes).

---

The format seems perfectly valid: %d.%m.%y %H:%M:%S%3u with a comma as decimal separator for

---

Oops, indeed the format is valid -- I "got lost" in all the punctuation!

I try to stay away from lists with Time Stamps in them.  Depending on circumstances, I would have the "Time" column either be "Time elapsed since beginning of task" (which is recorded as Time 0, with a header line that may have the full-fledged "Time Stamp when the Data collection began" (sort of like a Waveform's t0) or have the "Time" column be "Time elapsed since the previous reading", where time is similar to "dt" (except it is a variable, rather than a constant).  The choice is which is easier for the User to intuitively grasp, based on the tasks being performed and how easy it is to glance at the data being presented (as strings) and "see what is important to the user".  [Clearly, by doing additions or subtractions of neighboring data, LabVIEW can easily go from deltas to time points within a blink of an eye -- it's the slow Human looking at the numbers I'm thinking about.]

BS

[GuentherS]

Dear all

thanks for your answers

We did some more tests. We did a repeated ping to the instruments, without the Labview EXE running at all

We found that the ping to ALL instruments fails every now and then, but recovers. So the dropout of communication does not seem to be a problem of the software or Labview at all.

But why can't the EXE recover, when communication is back again?

Thanks 

Guenther