# Root Cause of Issue

**URL:** <https://forum.inductiveautomation.com/t/root-cause-of-issue/10906>\
**Category:** General Discussion\
**Created:** [December 11, 2015, 7:53pm UTC](https://forum.inductiveautomation.com/t/root-cause-of-issue/10906 "2015-12-11T19:53:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jim\_lapratt](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jim\_lapratt](https://forum.inductiveautomation.com/u/jim_lapratt)\
**Post date:** [December 11, 2015, 7:53pm UTC](https://forum.inductiveautomation.com/t/root-cause-of-issue/10906/1 "2015-12-11T19:53:03Z")

</div>

This type thing rolls through the log and its not always the same PLC. Looking for how to troubleshoot this to determine if its a network issue, PLC issue, driver issue or ?

[attachment=0]PLC.png[/attachment]

---

<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:** [December 11, 2015, 8:13pm UTC](https://forum.inductiveautomation.com/t/root-cause-of-issue/10906/2 "2015-12-11T20:13:14Z")

</div>

Basically what the log is saying is that a request was sent out and a response was not received before the communication timeout elapsed.

Often the cause is that the PLC doesn’t have enough time for all the comm it needs to handle, but it could be dropped packets or something else.

---

<div class="post-metadata">

**Author:** ![jim\_lapratt](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jim\_lapratt](https://forum.inductiveautomation.com/u/jim_lapratt)\
**Post date:** [December 11, 2015, 8:29pm UTC](https://forum.inductiveautomation.com/t/root-cause-of-issue/10906/3 "2015-12-11T20:29:12Z")

</div>

Ya, I have played with increasing the timeout, it helps.

Is there a rule of thumb for how high it can be set? There is no machine control here.

---

<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:** [December 11, 2015, 8:36pm UTC](https://forum.inductiveautomation.com/t/root-cause-of-issue/10906/4 "2015-12-11T20:36:34Z")

</div>

I don’t think everyone agrees with this approach, but I would advocate for keeping the timeouts as short as possible. During whatever the duration of the timeout is there are no\* other requests going out, so if the timeout ends up being due to a packet drop, and you’ve got a 5 second timeout, that’s 5 seconds there the driver was doing nothing.

- this is not entirely true on drivers that support concurrent requests, like ControlLogix, but the same pitfall applies if you end up with N requests, where N=concurrent requests, stalled and waiting for the timeout to elapse.