Filter
Top Products
Serial Protocols
RS400 61 ROS™ v3.5
an exception to the originator. If sending exceptions has not been enabled, the Server Gateway
will not send any response.
2.2.2.2 A Worked Example
A network is constructed with two Masters and 48 RTUs on four Server Gateways. Each of the
Masters 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.
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 650 to 1250 ms (additional 250 ms (server->RTU) + 100 ms (Think time) + 250
ms (RTU->server)).
The preceding analysis suggests that the Master should time-out at some time after 1250 ms
from the start of transmission.
2.2.2.3 Use of Turnaround Delay
Modbus protocol uses the concept of a turnaround delay in conjunction with broadcast
messages. When the host sends a broadcast message (that does not invoke an RTU
response), it waits for a turnaround delay time. This delay ensures that the RTU has enough
time to process the broadcast message before it receives the next poll.
When polling is performed over TCP, network delays may cause the broadcast and next poll to
arrive at the remote server at the same time. Configuring a turnaround delay at the server will
enforce a minimum separation time between each message written out the serial port.
Note that turnaround delays do not need to be configured at the host computer side and may be
disabled there.