Filter
Top Products
Chapter 22 - Configuring Serial Protocols
Steps 5-8 represent the case where the request is responded to by the RTU and is
forwarded successfully to the master. It includes the “think time” for the RTU to
process the request and build the response.
Step 9a represents the possibility that the RTU is offline, the RTU receives the request
in error or that the Server Gateway receives the RTU response in error. If the Server
Gateway does not retry the request, it will issue an exception to the originator.
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.
RuggedCom 203