RuggedCom RuggedRouter RX1100 - Manual (Page 221)

24. Configuring Serial Protocols
Revision 1.14.3 221 RX1000/RX1100™
24.1.5.6. A Worked Example
A network is constructed with two Masters and 48 RTUs on four Server Gateways. Each of the Master
is connected to a Client Gateway with a 115.2 Kbps line. The RTUs are restricted to 9600 bps lines.
The network is Ethernet based and introduces an on average 3 ms of latency. Analysis of traces of
the remote sites has determined that the min/max RTU think times were found to be 10/100 ms. What
time-out should be used by the Master?
The maximum sized Modbus message is 256 bytes in length. This leads to a transmission time of
about 25 ms at the Master and 250 ms at the RTU. Under ideal circumstances the maximum round
trip time is given by: 25 ms (Master->client) + 3 ms (network delay) + 250 ms (server->RTU) + 100
ms (Think time) + 250 ms (RTU->server) + 3 ms (network delay) + 25 ms (client->Master). This delay
totals about 650 ms.
Contrast this delay with that of a “quick” operation such as reading a single register. Both request and
response are less than 10 bytes in length and complete (for this example) in 1 and 10 ms at the client
and server. Assuming the RTU responds quickly, the total latency will approach 35 ms.
It is also necessary to take account such factors as the possibility of line errors and collisions between
masters at the server.
The server may be configured to recover from a line error by retransmitting the request. Given a
maximum frame transmission time of 250 ms and an RTU latency of 100 ms, it would be wise to budget
350 ms for each attempt to send to the RTU. Configuring a single retransmission would increase the
end-to-end delay from about 650 ms to about 1000 ms.
The server can already be busy sending a request when the request of our example arrives. Using
the figures from the above paragraph, the server being busy would increase the end-to-end delay
from 1000 to 1350 ms.
The preceding analysis suggests that the Master should time-out at some time after 1350 ms from
the start of transmission.
24.1.6. DNP (Distributed Network Protocol)
RuggedRouter supports DNP 3.0, commonly used by utilities in process automation systems. DNP3
protocol messages specify source and destination addresses. A destination address specifies which
device should process the data, and the source address specifies which device sent the message.
Having both destination and source addresses satisfies at least one requirement for peer-to-peer
communication since the receiver knows where to direct a response. Each device supporting the
DNP protocol must have a unique address within the collection of devices sending and receiving DNP
messages.
24.1.6.1. Address Learning for DNP
RuggedRouter implements both local and remote address learning for DNP.
A local Device Address Table is populated with DNP Addresses learned for local and remote DNP
devices. Each DNP address is associated with either a local serial port or a remote IP address.