Slow Communication Thro Modbus


Thread Starter

Peter D'Couto

We have a network of modbus serial communications. Some of the serial networks are pretty slow (takes a minute to communcate). We have noticed this especially with the write signals. Is there something that could be done with the address/ setting etc to make this communicate faster.

Peter D'Couto


modbus is slower in the responce. you can try by increasing the baud rate for all the slaves and half duplex to full duplex mode if the slaves support the configiration.

reducing the number of slaves also increase the responce speed. reduce unwanted data read in each slave.

If the slave have facilities for data packet then use them to pack the data so that at one stretch you can read all the datas.

Linnell, Tim

If you're using an AB Modbus module based on the Basic Module, they are (or at least were a couple of years ago when I was looking at them) ridiculously slow. Prosoft do an excellent alternative: there are some details at

Increasing slave baud rate probably won't help much as slave latency is constant at all baud rates, and actual transmission time improvement is
subject to the law of diminishing returns. Modbus is intrinsically half duplex (even on a full duplex media) so this suggestion won't work.

Optimising data into block reads (where possible) even when unnecessary data is included, will help a little. Bear in mind you have at least a 3.5
character time overhead on each request, plus the modbus request request packet size of about 8 bytes or so, plus response overhead of 5 bytes - all this is overhead on a single transaction, i.e. about 16ms at 9600 baud. The more transactions you do, the more the overhead dominates actual useful bandwidth use. But I suspect you have more fundamental problems to solve than this.


Check the number of retries and errors on the network. Commonly people will 'overload' a modbus Serial network by attempting to many request and having too small a timeout time.

Consider this : A master sends a request, the slave recieves the request but is slow to respond, so the master times out and then resends the request, the slave now trys to responds to the initial request - but this is ignored by the master as it is now sending the retry.

This type of comms on a serial line can cause a large number of errors/retries and give slower than expected communications.

But as others have said you are eventually limited by the response time of the slave devices and the number of slaves you are trying to poll.

Lynn August Linse

You didn't mention the vendor, but be aware that not all Modbus/RTU drivers are created equal. Sure all PLC vendors (Siemens, AB, Omron, GE, Modicon) now offer some way to get Modbus/RTU on certain PLC models. Yet some of them do it with BASIC interpreters or other programmable modules. Plus I'd expect some of those vendors have NO incentive to support fast Modbus polling as they prefer you to NOT use Modbus. They only offer Modbus as an economic necessity, not to make your life easy!

Also, some multi-CPU products can have very different response times based on what you ask. Some data may be cached in the comms CPU and answered very fast. Other values must fetched by CPU-to-CPU comms, possibly across a common RS-485 serial backplane. Also if your write is being saved to EEPROM or Flash, that can incur very long delays. I also worked a triple-modular
redundant system once where the a Modbus read took about 100-200msec to START to answer, but a Modbus write (due to voting and roll-back etc) to up to 800msec to start to answer.

Best Regards

Lynn August Linse, alist (at)
Foothill Ranch CA 92610 USA
Ph/Fx: 949-916-1524 (auto-detect voice or fax)