# DNP3 Device Connection Status & Timeout

**URL:** <https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660>\
**Category:** Ignition\
**Created:** [October 25, 2022, 4:12pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660 "2022-10-25T16:12:04Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\
**Post date:** [October 25, 2022, 4:12pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/1 "2022-10-25T16:12:04Z")

</div>

Is there a way to change the connection timeout? I can disrupt communications (by turning of the Ethernet switch) between my device and the gateway and the status `[default]foo/bar/PM-04-01/Device/Status` shows `Connected` for about 15 minutes before it changes to `Reconnecting Wait`.

Additionally, the device connection status on the gateway shows `Reconnecting Wait` for several minutes before `[default]foo/bar/PM-04-01/Device/Status` changes.

v8.1.18

Thank you.

---

<div class="post-metadata">

**Author:** ![obober](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/obober/32/67865_2.png) [@obober](https://forum.inductiveautomation.com/u/obober)\
**Post date:** [October 25, 2022, 8:50pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/2 "2022-10-25T20:50:32Z")

</div>

Have you played around with the `Message Timeout` and `Retry` parameters in your DNP3 device configuration? These will allow you to change the amount of time that Ignition waits for a response.

However, 15 minutes is a long disconnect time: I think that is happening because you are severing the connection between the device and Ignition in a non-clean way. "Dirty" network disconnects are normally much harder to configure in ways like that. Since this is a direct connection between the GW and the DNP3 device, I'm not sure where else you'd be able to configure the timeout.

---

<div class="post-metadata">

**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\
**Post date:** [October 25, 2022, 9:08pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/3 "2022-10-25T21:08:16Z")

</div>

Hi Oles,

`Message Timeout` is set to 5000 and `Retries` is set to 0, I'd like to keep them this way, it's critical device and if we lose comms I want to know about it immediately.  
We can't change the network design, we have to live with it.  
Why doesn't `[default]foo/bar/PM-04-01/Device/Status` change value after (5 seconds)?

Thanks,  
Ted

---

<div class="post-metadata">

**Author:** ![obober](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/obober/32/67865_2.png) [@obober](https://forum.inductiveautomation.com/u/obober)\
**Post date:** [October 25, 2022, 9:28pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/4 "2022-10-25T21:28:09Z")

</div>

So I just realized my first post may have been a bit misleading.

Those settings I mentioned earlier are for configuring how Ignition responds to no message being received _when the DNP3 device is connected_. That status tag you are seeing under the System Tags corresponds to the status of Ignition trying to make a valid connection with the device itself. Since the device is not visible to Ignition, Ignition will continue trying to connect to that device persistently.

However, something sounds strange to me, are you saying that the tag shows `Connected` for multiple minutes before switching to `Reconnected Wait`? Does the device status under the Status \> Connections \> Devices page on your gateway web page show the same thing consistently? Or does the tag "lag" behind that status?

---

<div class="post-metadata">

**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\
**Post date:** [October 25, 2022, 9:43pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/5 "2022-10-25T21:43:13Z")

</div>

**Yes** , that tag show `Connected` for many minutes before changing to `Reconnect Wait`.  
**No** , the device status under the Status \> Connections \> Devices page on my gateway web page show doesn't show the same thing, it will show `Reconnect Wait` minutes before the tag changes.

---

<div class="post-metadata">

**Author:** ![obober](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/obober/32/67865_2.png) [@obober](https://forum.inductiveautomation.com/u/obober)\
**Post date:** [October 26, 2022, 10:13pm UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/6 "2022-10-26T22:13:32Z")

</div>

That sounds sort of like a bug; the tag value doesn't change correspondingly with the actual device status. Since this requires replication with a DNP3 device (which I don't have), I recommend you open a ticket with our support department to confirm if this is a bug or if there is something else at play here.

---

<div class="post-metadata">

**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\
**Post date:** [October 27, 2022, 11:30am UTC](https://forum.inductiveautomation.com/t/dnp3-device-connection-status-timeout/65660/7 "2022-10-27T11:30:22Z")

</div>

> [@obober](#):
>
> I recommend you open a ticket with our support department to confirm if this is a bug or if there is something else at play here.

Done! Thanks Oles.  
Regards,  
Ted.
