keep alive VISA communication with LAN

[ESteb]

HI, 

I have 6 TDK Lambda power supply connected via LAN to my computer. They are working it time periods, like set output, wait couple hours, set output, wait couple hours, and again. On TDK devices maximum time for keeping alive LAN connection without any traffic is 16,5 hour. Sometimes period between sending messages is longer than that 16,5h. 

Solution for that could be keep alive packets that are available function for VISA

After setting this option for true connection is still closed.

Do You know how can I set up more options for this keep alive option?

I found that default windows parameters for keep alive packets are 2h period between sending packet and 3 times retry before closing connection.

This didn't solve closing connection so can you tell me how can I better setup this option to make it work?

LabVIEW examples and help didn't show this option very well.

[Worle]

I've not used the 'keep alive packets' that you discussed below so I can't comment on their inner workings.

Instead I am perhaps going to ask the simpler question. Why don't you just create periodic traffic? Surely there is an innocuous setting that you could read every hour which won't effect the operation of the power supplies whilst still generating traffic to keep the comms open?

[ESteb]

Your proposal is more like workaround solution that will work. But if there is keep alive feature I would like to know how to use it with all details. 

Thank You for reply. 🙂

[rolfk · Accepted solution]

The idea with calling an innocent read command might not just be a workaround but the real solution, depending on how the device implements its inactivity timer.

The TCP keepalive feature is a low level socket function where the actual TCP/IP driver starts a timer and then whenever the timer counts down to zero it will send a keep alive TCP packet with NO DATA.

The socket on the other side will see that packet and simply send a TCP ACK in response. The idea is not so much to keep your other device alive but to make sure there is periodic traffic on the link that might keep the connection infrastructure alive such as not dropping a dialup connection because of inactivity. Also if the ACK doesn't arrive after a certain amount of time, the connection will be considered broken and higher level protocol handlers will pass this error up to your application so you get in LabVIEW an error 59 or 66.

It is very likely that the functionality to drop the connection after a certain amount of time without any activity is actually located in the application layer of your TDK device. That layer has absolutely no knowledge of low level TCP/IP packet transmissions but only sees the data payload in those packets. Since the keepalive TCP/IP packet is an empty packet with no data payload, the application layer will never see that packet and therefore the function to not drop the connection after some time of inactivity will be unaffected.

[Karmiel]

There is no VISA/TCP keep alive function for this device, you should send command/query at least once per 16.5h.

 Unfortunatelly, there is no better solution for that.

[RTSLVU]

I think you all are over complicating this:

If all you have to do is send is a command to keep the connection "awake".

Why not just send it a *IDN? query once an hour?

[billko]

---

@RTSLVU wrote:

I think you all are over complicating this:

If all you have to do is send is a command to keep the connection "awake".

Why not just send it a *IDN? query once an hour?

---

The OP considers this a "workaround".  I would say it's a perfectly valid way to keep a connection open the instrument, not a workaround.  More robust, too.  Every SCPI-capable instrument will respond to this command.  It would be hit or miss with the heartbeat thing.  Something like that might be subject to implementation incompatibilities, too, where two companies might interpret the requirements differently and even though they both support the feature, they are incompatible with each other.

[ESteb]

Thank You for this information.

I was wondering if this "keep alive" message is passed to higher level layers, but it is as You said so. I could not get any information about passing empty Ethernet messages in TDK devices so I have to assume that it is not passed.