22. Serial Protocols
ROX™ v2.2 User Guide
223
RuggedBackbone™ RX1500
In step 1, the master issues a request to the Client Gateway. If the Client Gateway validates the message
it will forward it to the network as step 2.
The Client Gateway can respond immediately in certain circumstances, as shown in step 1a. When the
Client Gateway does not have a configuration for the specified RTU it will respond to the master with an
exception using TcpModbus exception code 11 (“No Path”). When the Client Gateway has a configured
RTU but the connection is not yet active it will respond to the master with an exception using TcpModbus
exception code 10 (“No Response”). If the forwarding of TcpModbus exceptions is disabled, the client
will not issue any responses.
Steps 3a and 3b represents the possibility that the Server Gateway does not have configuration for the
specified RTU. The Server Gateway will always respond with a type 10 (“No Path”) in step 3a, which
the client will forward in step 3b.
Step 4 represents the possibility of queuing delay. The Server Gateway may have to queue the request
while it awaits the response to a previous request. The worst case occurs when a number of requests
are queued for an RTU that has gone offline, especially when the server is programmed to retry the
request upon failure.
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.
22.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.
