Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel

DNP3 timeouts on outstation with unreliable comms

EcoStruxure Geo SCADA Expert Forum

Find out how SCADA systems and networks, like EcoStruxure Geo SCADA Expert, help industrial organizations maintaining efficiency, processing data for smarter decision making with IoT, RTU and PLC devices.


DNP3 timeouts on outstation with unreliable comms

I have a SCADAPack ES outstation on a poor RF link that is generating fleeting comms fail alarms that resolve in a few minutes. The RTU used to talk on a serial network which was recently upgraded to Ethernet.


This is a low-criticality site where it has a daily integrity poll and an hourly Class 1 poll. The fleeting comms alarms are triggering on the hourly Class 1 polls at around the same period of time every night.


Looking at the DNP3 logs, most of the comms alarms seem to be following the same sequence of events:

  1. The outstation channel sends the Class 1 poll request.
  2. Comms fail alarm is raised on SCADA after 40-50 seconds.
  3. The channel does not send any requests to the outstation for the next 6-7 minutes.
  4. After 6-7 minutes, the channel sends an MDRP comms start request which the outstation responds to fine and this clears the comms fail alarm on SCADA.


I'm trying to tune the DNP3 timeouts to stop those fleeting alarms from occurring and give the RTU more time to respond properly without causing SCADA to raise nuisance alarms. I have a few questions around that process:

  1. In this short KB article, it is mentioned that there are issues when Geo SCADA's AL timeouts are shorter than the outstation as it causes SCADA to do faster retries than what the outstation is able to respond to. However, the recommendation is "To prevent this issue from occurring, the outstation AL timeout should be greater than the ClearSCADA AL timeout (usually by at least a couple of seconds)". Shouldn't the outstation AL timeout be shorter than the SCADA AL timeout to prevent this issue from occurring?
  2. Why am I not seeing the outstation channel attempt another Class 1 poll request when it does not receive a response for the initial request from the outstation?
  3. Why do I see a comms fail alarm raised 40-50 seconds after the initial request? Is this due to the DL timeouts?
  4. Is it possible to have SCADA alarm on a failed MDRP comms start rather than the failed Class 1 poll request?