TCPIP connection to instrument closing after being idle for 6 seconds

[edjub]

I've been using the NI-VISA library in Excel VBA for controlling various instruments using TCPIP raw sockets.  Without any change to the VBA programming, connections to instruments started reporting I/O errors. Apparently something other than my VBA code is closing the socket.

For debug, I wrote a simple macro in VBA to loop sending instrument commands at a periodic rate.  The macro would run indefinitely without error.  If I pause it, the connection will close after 6 seconds, indicated by the "remote" light on the instrument extinguishing.  Resuming the script would result in an I/O error message.

Back then (three months ago) we rolled back the NI-VISA version (to 2019, I believe), and that fixed the problem temporarily.  A month later, the problem came back even though the system still thought the older NI-VISA version was installed.  My guess is that something had changed in an automatic Windows update (e.g., a driver used by NI-VISA) to break the connection.  My workaround was to rewrite the script to use direct raw socket programming, avoiding NI-VISA altogether, and haven't had any problem with that Excel VBA script since.

The same problem has just resurfaced in a different Excel VBA script that had previously worked.  This time, the script is talking to a different instrument from a different manufacturer.  The only commonality is using the NI-VISA library for TCPIP connections from VBA.  Unfortunately, this instrument only supports the VXI-11 TCP/IP Instrument Protocol, not direct raw sockets.

Is there something new in the latest NI-VISA drivers that requires me to "enable keepalive" or take some other action to make a connection persist while my script is off doing other things?  How do I fix this?

[grasia4]

if you facing a problem like TCP/IP connection to an instrument is closing after being idle for 6 seconds so as i know TCP/IP connections have a concept of idle timeout, which specifies the maximum amount of time a connection can remain idle before it is considered inactive and closed. This timeout is typically configurable and can be adjusted to suit your requirements. I think you should check the settings on both the instrument and any network devices (routers, firewalls) that are involved in the connection. Look for configuration options related to TCP/IP connection timeouts. Specifically, you want to find and adjust the idle timeout value. 

[edjub]

I am familiar with TCP/IP keepalive functionality to maintain a socket connection when idle, but 6 seconds is an extremely short time.  Typical idle socket disconnection occurs after an hour, so a keepalive could be set up for every 30 minutes.  Sending keepalives every few seconds seems like insanity to me.

Using Wireshark, I determined that the NI-VISA drive had initiated the closing of the socket, not any external equipment and not the instrument under control.  I had given up on using NI-VISA in this application because I couldn't find any mechanism to control the timeout on the socket connection that NI-VISA established.   I know that the instrument I was controlling could communication with raw sockets, so I solved the problem by abandoning NI-VISA.

I suspect that a 6 second timeout was built into NI-VISA because many instruments are limited to a single connection and won't allow a second connection while one is already established.  I've dealt with instruments that hold onto a socket forever, so if something happens to cause the host application to terminate without properly closing the socket, the instrument is essentially offline until rebooted.