Details of the DNP3 Driver

This chapter is dedicated to advanced WinCC OA users. It describes the debug levels and provides information about the DNP3 driver.

Debug Levels

The following command line options can be used for identifying a possible source of error. Enter -helpdbg to display more information about other options.

Debug Debug level Description
DEBUG_WORK -dbg 2 General debug information.
DBG_API_USR1 -dbg 10 Debug information about establishing, disconnecting and monitoring of the connection.
DBG_DRV_WORK -dbg 24 Additional general debug information.
DEBUG_DRV_USR1 -dbg 25 Debug information concerning sent telegrams.
DEBUG_DRV_USR2 -dbg 26 Debug information concerning received telegrams.

Transformations

A transformation converts hardware data into a WinCC OA format. The transformation type of a data point element can be requested and set via integer constants. Using dpGet() or dpSet(), the attribute _address.._datatype must be used, too. For detailed information about the integer constants that are used for the DNP3 driver transformations, see chapter _address.

Freezing counters

This section describes how counters in a station can be frozen. For this purpose an output address must be configured for a data point element of type unsigned. Define the group "Counter" (20) as well as the corresponding index of the counter to freeze. The value of the corresponding data point element is not relevant and is only used to trigger the freezing of the counter. Use the function in the peripheral address (see Defining the Peripheral Addresses of the DNP3 Driver) to specify how the freezing shall be done. The following function codes are available:

  • 7: freeze

  • 8: freeze with no acknowledgement

  • 9: freeze and clear

  • 10: freeze and clear with no acknowledgement

Error messages

If an exception telegram has been received or sent, the error codes of the DNP3 driver are used and committed to the WinCC OA log viewer. The error message is automatically written into the WinCC OA log file and WinCC OA log viewer.

Polling

To ensure that poll performance may not be influenced, not all addresses can be read individually.

General Query

With the config entry integrityPollAtStartup the general query during a connection establishment can be deactivated/activated.

CAUTION: Normally polling is not used when using the DNP3 driver, since applying polling can result in poor performance under certain circumstances. An unsolicited data transfer or a single request will be carried out in this case.

Dual End Mode

The Dual Mode of the DNP3 driver lets the driver stay in a passive mode and only connect when requested by the RTUs.

This mode offers several advantages, such as:

  • Optimized for devices with limited power, like those powered by batteries or solar energy
  • Reduced communication overhead, which saves bandwidth
  • Lower operational costs
  • Improved sustainability by saving a significant amount of energy

To enable Dual Mode, you need to configure the listening port by setting the config entry [dnp3] tcpServerPort. Once set, the DNP3 driver will listen on the specified port for incoming RTU connections.

Additional settings can be adjusted in the DNP3 Driver Configuration panel:

  • You don’t need to set the connection to Active. Configuring the entry will automatically enable listening mode when the driver starts.
  • Setting the Host option to * allows RTUs with dynamic IPs to connect. If you specify an IP, only devices with that IP can communicate.
  • The LA (Link Address) set in the panel must match the one used by the RTUs. If they don’t match, requests will be refused, and no connection will be made. This feature also lets you assign specific RTU communications to a particular driver instance without needing to assign specific IPs in the configuration.
Restriction: The Dual Mode is only available for TCP communication.