Modbus Data transmission time


Thread Starter

Bhadresh Sarvaiya

I want time to update 10 holding register and 10 coil register at master side. If my slaves are connected by RS 485 in daisy chain and Baud rate: 9600, data bit: 8, stop bit: 1, parity: Even.
I am reading those data in SCADA.

Then how to calculate time to update all data?
Is it affect Time out of device and/or response time of devices?
What other parameter are required to calculate those time?
I'm using one converter to convert Modbus RTU to Modbus TCP, and in SCADA data scanned by 100Mbps Ethernet speed.
You know
- the word size, 11 bits
- the number of words in the master message
- silent interval of 3.5 characters to denote the start & end of message
- baud rate
- the slave response message size

There's some latency in the RTU/TCP conversion, so pick a value for that and you can calculate an ideal throughput rate.

But in the end, it's the slave wake-up and response times that determine the real-world throughput rate.

See Mr. Woodward's and Mr. Braun's salient comments on real-world performance in this golden-oldie (2000) thread:

It's as true today as it was back then.

Bhadresh Sarvaiya

Thank you for your kind reply..
but i didn't get answer as i want..
i didn't understand your reply..
can you explain me it in brief little more...

> You know
> - the word size, 11 bits
> - the number of words in the master message

---- snipped by Moderator ----

> See Mr. Woodward's and Mr. Braun's salient comments on real-world performance in this golden-oldie (2000) thread:

Curt Wuollet

It depends on how it's written. In the system I just set up, I use a state machine to do the sequencing.

It checks that the port is ready then does the read from the first slave, then waits for the port to be ready and does the write to the first slave and on to the second each time waiting for the port. This is called interlocking. I could also write it your second way. And then there is overhead and how often the device services the comm ports and other variables. That adds something to the actual baud rate divided by bits per character times message length. And it depends on just which commands you use and how they are implemented. So, it's a little hard to answer your question. But. you can find out with your equipment and setup. Get one one of the many free serial spy programs, Commfront comes to mind and watch the network. At 9600 baud, 400 registers are going to take a while. Even with minimum overhead.


Lynn August Linse

Just be careful to accommodate the delay-back off during failure. With a single device, it might not matter, but with a multidrop it can be a killer.

For example, assume you have 4 devices which normally reply in 100msec (0.1 sec), so all 4 can be polled in 0.4 second. But if one goes offline & the master does a slave-timeout of 1 seconds, it might now take about 1.3 seconds per cycle. That's fine if the master backs off, but if something keeps trying to poll every 0.1 second, you will build a large backlog.

Bhadresh Sarvaiya

> Mr. Linse,

> What's a rule-of-thumb value for RTU-TCP latency in a Digi Modbus bridge product?


I just want to know that how does it works?

First register is read from first slave and second from second slave like this or first, second, third tends to tenth register and another all 10 coil register from first slave only and then goes to second slave like this??

Lynn August Linse

>> What's a rule-of-thumb value for
>> RTU-TCP latency in a Digi Modbus bridge product?

Latency is fairly low - 10's of msec for the queuing/multi-threaded overhead. Literally what happens is:

1) a 'server' thread receives the Modbus/TCP request. It has been in a 'select()' like wait.

2) the 'server' decodes the packet, examines the Unit-Id, scans what is called the 'routing table' to see which 'client' thread will obtain the response. Most Digi bridges allow from 32 to 64 active threads for this.

3) Once found, it adds the request (which has been 'normalized' to a Modbus PDU, so not TCP or RTU), then it signals the 'client' thread of work pending.

4) The 'client' thread may be idle, or it may be in the middle of a transaction. It does what is required to manage the Modbus transaction.

5) Nothing in the 'server' thread prevents it from handling another transaction, and even queuing a 2nd/3rd transaction for the same 'client' thread.

6) various timers cause stale requests to time out if the 'client' doesn't get to them in time, which prevents an infinite queue build up.

But back to your original question, there is some latency in the 'select()' and 'signal()' mechanisms, but it tends to be small compared to the serial-shift latency. For example a 250 byte packets takes about 205msec to shift at 9600 baud. Many pipeline/customers prefer a multi-port unit (like 4 or 8) then run pumps/PLC pt-to-pt so there are no timing dependencies between devices ... no shared resource; no shared serial bandwidth.

Of course, if you have 6 slaves on an RS-485 multi-drop; if the master polls all 6 in 'pipeline' fashion, and if each transaction takes 200msec to complete, then the perceived latency of the first poll is 200msec, the second 400msec, the third 600msec, (etc) as they all need to wait in queue for the 'client' thread to process.

>>I just want to know that how does it works?

Nope. A common bridge can't poll slaves on its own. The bridge is 100% passive. It waits for an external Master to give it a request, which it obtains a response for, then it goes idle. Now, some competing products *DO* allow you to define a poll-list internally, so they poll with or without external masters being active. I don't call those bridges though - they are more gateways or concentrators or something else fancy. A 'bridge' is just an on demand translator, allowing external masters to talk to/share external slaves.

Had I not stopped working on the Digi 'bridge' code back in 2006, I had been designing a form of 'pre-fetch' cache, where the bridge assumed past polls would repeat & pre-fetch until no one asked that same question anymore (so the cache went unused). But that never was put into place, asmy bosses first moved me to cellular coding, then wireless XBee/ZigBee/900Hmz mesh, etc. Someday I'll start up a Python bridge code, then I can add that back in.

Patrick Lansdorf


I have made a simple Excel sheet, where one can calculate the line time. You will need to know the response time of the slave, though...

If anyone wants it, email me at pal(at)