![]() ![]() |
We are mainly in Industrial Automation. We develop products like Fault relays, Soft starters, VFD. For one of our product (soft Starter) we are using Modbus ASCII and RTU. We have some queries about Modbus protocol.
We developed Modbus ASCII mode (Slave device) as per your implementation guideline ˇ§Modbus over serial lineˇ¨. Now we are developing RTU mode.
In RTU mode as per your guideline, there should be at least 3.5 char (t3.5) silent interval between two frames & there should not be silent interval more 1.5 char (t1.5) between two char.
As per baud rate these inter frame delay (t3.5) and inter char delay (t1.5) are as follows
1 Byte = start + 8 bits + parity + stop = 11 bits
Baud rate t 1.5 (16 bits) t 3.5 (38 bits)
1200 13333.3 us 31666.7 us
4800 3333.3 us 7916.7 us
9600 1666.7 us 3958.3 us
19200 833.3 us 1979.2 us
38400 416.7 us 989.6 Us
We developed program structure for RTU mode. We are using Silabs c8051F020 controller. For our structure time required to decode, action and generate response takes 50 ms time.
The demo test software we are using is Modbus Poll test software developed by Witte Software Web site: http://www.modbustools.com
Note:
* Modbus Poll Software setting - Response time out ˇV 200 ms and Delay between poll ˇV 200 ms
Practically what we have observed is as follows:
1. When we put these timings for baud rate 1200 and 4800 there is no error in communication.
2. But from 9600 to 38400 baud rates we observed "Byte missing error" or "time out error".
And as per your guideline, baud rates above 19200, one should use t3.5 ˇV 1.750 ms & t1.5 ˇV 750 ms.
But practically, we observed, for 9600, 19200 & 38400 baud rates if we put t3.5 ˇV 4.650 ms & t1.5 ˇV 1.750 ms no communication error occurred. We want to know these timings are acceptable or not.
So kindly, give right direction for our development about these timings.
We developed Modbus ASCII mode (Slave device) as per your implementation guideline ˇ§Modbus over serial lineˇ¨. Now we are developing RTU mode.
In RTU mode as per your guideline, there should be at least 3.5 char (t3.5) silent interval between two frames & there should not be silent interval more 1.5 char (t1.5) between two char.
As per baud rate these inter frame delay (t3.5) and inter char delay (t1.5) are as follows
1 Byte = start + 8 bits + parity + stop = 11 bits
Baud rate t 1.5 (16 bits) t 3.5 (38 bits)
1200 13333.3 us 31666.7 us
4800 3333.3 us 7916.7 us
9600 1666.7 us 3958.3 us
19200 833.3 us 1979.2 us
38400 416.7 us 989.6 Us
We developed program structure for RTU mode. We are using Silabs c8051F020 controller. For our structure time required to decode, action and generate response takes 50 ms time.
The demo test software we are using is Modbus Poll test software developed by Witte Software Web site: http://www.modbustools.com
Note:
* Modbus Poll Software setting - Response time out ˇV 200 ms and Delay between poll ˇV 200 ms
Practically what we have observed is as follows:
1. When we put these timings for baud rate 1200 and 4800 there is no error in communication.
2. But from 9600 to 38400 baud rates we observed "Byte missing error" or "time out error".
And as per your guideline, baud rates above 19200, one should use t3.5 ˇV 1.750 ms & t1.5 ˇV 750 ms.
But practically, we observed, for 9600, 19200 & 38400 baud rates if we put t3.5 ˇV 4.650 ms & t1.5 ˇV 1.750 ms no communication error occurred. We want to know these timings are acceptable or not.
So kindly, give right direction for our development about these timings.
![]() ![]() |
Dears experts:
I'm having the same problem. I'm using 8051F120 for developing a RTU client to 9600mbps. But when my client respond to the master this one reports "Time Out error" or "write error". do you know which is the problem?
I developing a this project for my thesis.
I'm having the same problem. I'm using 8051F120 for developing a RTU client to 9600mbps. But when my client respond to the master this one reports "Time Out error" or "write error". do you know which is the problem?
I developing a this project for my thesis.
![]() ![]() |
First, make sure your CRC16 is correct - many small compilers have precedence or type-conversion issues so that a 'proven' algorithm might not always work.
Second, make sure you calculate the CRC16 before you start to transmit, other wise you risk a tiny lag before the last 2 bytes are sent. I have seen this on some products - the Modbus response arrives literally in 3 pieces: the slave address, then the Modbus 'response', then the CRC16. You don't want this to be allowed.
So you need to create the response in a single complete byte buffer, then use a high-priority interrupt-driven algorithm to send it.
Second, make sure you calculate the CRC16 before you start to transmit, other wise you risk a tiny lag before the last 2 bytes are sent. I have seen this on some products - the Modbus response arrives literally in 3 pieces: the slave address, then the Modbus 'response', then the CRC16. You don't want this to be allowed.
So you need to create the response in a single complete byte buffer, then use a high-priority interrupt-driven algorithm to send it.
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2013 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
If you pick up a starving dog and make him prosperous, he will not bite
you. This is the principal difference between a dog and a man.
-- Mark Twain








