modbus tcp timeout

[Mike@Forshock]

Agreed it should retry.  I just ran tests on serial again to make sure it works just fine.

I submitted a ticket to NI and Ryan Shi directly.

[bkinard@kinardcontrolsyst]

I appreciate that. Definately needs to be a fix for that.

[Ryan.S]

Brian,

I'm looking at the log. It looks the communication is good although there are some socket errors. Most of the socket issue were resolved after one or two following calls and the polling recovered after that.

One continuous failure happened from 15:19:18.5 to 15:26:50.2 . The socket was not recovered during that time. However, it became good after that.

So, how about the data in your Lookout process? I want to understand if the problem is in data communication, or just the alarms. Maybe the communication recovers but the alarm is not cleared.  

[bkinard@kinardcontrolsyst]

The problem is that Lookout is ignoring the retries. I have the number of retries set to 10 but I get red X's after one fail. On my trend charts, I get blank data because Lookout doesnt log during that time. What it looks like to me is that Lookout isnt retring no matter what the number of retries is set to. It assumes that after one "no response" that the site has lost com.

So, to answer your question, I am losing data because its not retrying.

[bkinard@kinardcontrolsyst]

As you can see below, my communication is nearly perfect but a lot of data gaps.

[Ryan.S]

What's the Receive Timeout you set? In advanced setting, what's your "Skip xxx poll after comm failure"?

I guess I understand your problem. The "retry" happens when there is no valid response or timeout.(see its help) However, the log shows that the socket connection is intermittent. Sometimes the socket is disconnected. This is not invalid response or timeout, but recognized as a communication failure by Lookout. For communication failure, the "skip xxx polls" takes effect and "retry" will not happen. By default it's 4. So, if the poll rate is 2 sec, the next socket connection will be 12 sec later.

Try to reduce "skip xxx poll" and see if the gap on trend will be smaller.

[bkinard@kinardcontrolsyst]

Receive timeout is set to 3500 seconds. I have set it higher and lower with no significant results. I have also tried setting the skip polls to 1, 2, 3, and 4. Lookout still does not retry. One bad poll = red X's no matter what the number of retries is set to. Even if I set the timeout to 1ms or 7500ms, if the retry attempts is set to 10, it should try 10 times before giving red X's on the screen and creating data gaps.

I get the fact that I am going to get a bad poll or two once in a while, the problem is that its not retrying.

[Mike@Forshock]

As Brian mentioned, it ignores retries.

Even setting Skip to 0 does not solve that problem.  If the socket disconnects, it should retry until it reaches the retry count then show bad quality.

[bkinard@kinardcontrolsyst]

Here is the progression. Retries are set to 10. This was taken right after I reopened the program.

[bkinard@kinardcontrolsyst]