• Configuration/Communication/DNP3.0/DNP3.0n/Data link confirm
• Configuration/Communication/DNP3.0/DNP3.0n/Data link confirm TO
• Configuration/Communication/DNP3.0/DNP3.0n/Data link retries
• Configuration/Communication/DNP3.0/DNP3.0n/App layer confirm
• Configuration/Communication/DNP3.0/DNP3.0n/App confirm TO
DNP3 link layer acknowledgements should not be used in TCP/IP link mode, since the
DNP3 message transport (link) is then encapsulated and secured by the Ethernet
protocol.
Link layer acknowledgements are seldom used in serial mode. The application layer
acknowledgements also cover the link layer acknowledgements. This means that if the
application message was successfully delivered, then the link layer must also have
been successful. Furthermore, it is easier to perform a whole application layer
retransmission rather than link layer retransmissions. Otherwise the application layer
timeout must be prepared to cover all the timeouts and retransmissions performed by
the link layer.
3.3.3 Polled mode
In the polled mode the client station initiates a connection and polls periodically for
static data (Class 0), and events (Class 1/2/3) from the server. Data must be polled
frequently enough, to prevent event overflow. If event overflow takes place, this is
indicated in the IIN bits in the response message. This means that events have been
lost.
3.3.4 Unsolicited reporting mode
Unsolicited mode can be enabled in the relay by the UR mode parameter. The
operating principle is that the server sends event data spontaneously to the client.
When the unsolicited mode has been activated by the setting parameter, the client
station must activate UR reporting by Enable unsolicited Application function (20).
After activation the server begins sending Class 1/2/3 events spontaneously.
Client must acknowledge unsolicited events reported by the server to ensure the
communication is fully operative. If the server does not receive acknowledgement in
time, defined by the UR TO and App confirm TO parameters, it does a count of resends
defined by the parameter UR retries. If the client station does not respond
acknowledgement during the count of retries, the server goes to offline mode. This
means that spontaneous events are not sent for a period of time. The length of this
period is defined by the parameter UR offline interval, (default 15 minutes). If it is not
wanted that the server goes to offline mode, limitless retries can be achieved by setting
the UR retries to “65535”.
Class event reporting can be buffered in the unsolicited mode by setting the
parameters UR Class x Min event and UR Class x TO. The event parameter UR Class
x Min defines how many events must be buffered in the device before unsolicited
report is sent out. The UR Class x TO parameter in turn defines the minimum waiting
1MRS758757 A Section 3
Vendor-specific implementation
REC615 and RER615 13
Communication Protocol Manual
To Next Page
Loading...
