# Modbus TCP Request Failed

**URL:** <https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147>\
**Category:** Ignition\
**Created:** [November 29, 2018, 8:11pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147 "2018-11-29T20:11:31Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![joshuaksutherland](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joshuaksutherland](https://forum.inductiveautomation.com/u/joshuaksutherland)\
**Post date:** [November 29, 2018, 8:11pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/1 "2018-11-29T20:11:31Z")

</div>

Hey all,  
Just wanted to delve deeper into this problem because I want to understand what might be happening. I have a PLC in the field that I am polling every 20,000ms for data using Modbus TCP. The Timeout is 2,000ms and the Stale rate is 20,000ms.

It works great. Problem is, the moment I increase the poll rate to 30,000ms or greater it starts disconnecting pretty consistently and throwing this error:

java.lang.Exception: RequestCycle stopped.  
at com.inductiveautomation.xopc.driver.api.BasicRequestCycle$AddToQueue.run(BasicRequestCycle.java:115)  
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)  
at java.util.concurrent.FutureTask.run(Unknown Source)  
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)  
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)  
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)  
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)  
at java.lang.Thread.run(Unknown Source)

The log says: ReadHoldingRegistersReques 29Nov2018 10:06:26 Request failed. FailureType==DISCONNECTED

Then if I switch the reads back to 20,000 ms it will work perfectly. Any ideas on why this is happening? I would love to be able to read at 3-4 minute intervals to save on data.

Thanks!

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\
**Post date:** [November 29, 2018, 8:21pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/2 "2018-11-29T20:21:11Z")

</div>

I’m not sure, but shouldn’t you change the stale rate to something greater than the polling rate?

---

<div class="post-metadata">

**Author:** ![joshuaksutherland](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joshuaksutherland](https://forum.inductiveautomation.com/u/joshuaksutherland)\
**Post date:** [November 29, 2018, 8:26pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/3 "2018-11-29T20:26:42Z")

</div>

I had to go do some reading on this. It seems the Stale Rate is not even used by the Internal Tag provider (OPC-UA) which I am running the tags through. Instead the Stale Multiplier is used which is a default of 5 times the fastest rate. This should go up automatically when I increase the poll rate to 30,000. At least that is my understanding. I will try increasing the stale rate when I increase the poll rate just in case and see.

Thanks for the response!

Edit: Upon testing this by changing the poll rate to 30,000 and the Stale rate to 150,000 the same thing happened with the disconnects just as expected.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [November 29, 2018, 8:51pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/4 "2018-11-29T20:51:02Z")

</div>

> [@joshuaksutherland](#):
>
> Then if I switch the reads back to 20,000 ms it will work perfectly. Any ideas on why this is happening? I would love to be able to read at 3-4 minute intervals to save on data.

This is happening because the Modbus TCP spec suggests that slaves close the connection after a period of inactivity and the device you're talking to is doing so somewhere between 20 and 30 seconds.

Unfortunately our driver really doesn't handle this well - it always treats a disconnect as a bad event and immediately starts reconnecting.

---

<div class="post-metadata">

**Author:** ![joshuaksutherland](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joshuaksutherland](https://forum.inductiveautomation.com/u/joshuaksutherland)\
**Post date:** [November 29, 2018, 8:54pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/5 "2018-11-29T20:54:13Z")

</div>

Thank you Kevin. So this is basically part of using Modbus TCP? I should use something like MQTT if I want to have reads that are further then x amount of time apart? (Where X is where ever that implementation of Modbus disconnects at?)

Is there a good work around you know of like sending KeepAlive pings or something?

-Josh

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [November 29, 2018, 8:59pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/6 "2018-11-29T20:59:34Z")

</div>

Honestly, our driver should just handle this better by not treating disconnects as catastrophic and setting bad quality when it happens and then not immediately reconnecting until the connection is needed again. Unfortunately this kind of fundamental change to the driver isn’t going to be able to happen until something like 8.1 timeframe.

As a workaround, you can keep a single tag polling at ~20s while the rest poll at the slower rate.

As another workaround, you can use Kepware instead, which handles this situation more gracefully.

---

<div class="post-metadata">

**Author:** ![joshuaksutherland](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joshuaksutherland](https://forum.inductiveautomation.com/u/joshuaksutherland)\
**Post date:** [November 29, 2018, 9:00pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/7 "2018-11-29T21:00:45Z")

</div>

Wonderful. Well please put the suggestion in for me, since we will be using Ignition when 8.1 does eventually come out. Thank you for the suggestions, I will make use of them.

-Josh

---

<div class="post-metadata">

**Author:** ![daniel4](https://avatars.discourse-cdn.com/v4/letter/d/cdc98d/32.png) [@daniel4](https://forum.inductiveautomation.com/u/daniel4)\
**Post date:** [May 10, 2025, 6:12pm UTC](https://forum.inductiveautomation.com/t/modbus-tcp-request-failed/21147/8 "2025-05-10T18:12:18Z")

</div>

Can confirm this is still a problem.  
Request failed. FailureType==DISCONNECTED  
To minimize traffic you can make a tag group just named keepAlive or something and poll one value on each device like previously suggested. (I suggest around 5 second poll rate should be fast enough for most things)  
And if you have access to the device and it has the capability you can change the timeout on the device if applicable.
