I've been reading the "Modicon Modbus Protocol Reference Guide", PI-MBUS-300 Rev. J that I downloaded off of MODBUS.ORG. And have come across some conflicting information, and need it clarified. In Chapter 1, Section "RTU Framing", Page 9, there are two paragraphs that talk about timing. See below.

---
The entire message frame must be transmitted as a continuous stream. If a silent interval of more then 1.5 character times occurs before completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a new message.

Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a continuation of the previous message. This will set an error, as the value in the final CRC field will not be valid for the combined messages. A typical message from is shown below.

---

So in the first paragraph, if I have a blank spot in the data stream of 1.5 character times, I throw out what I have, and consider the next byte the start of a new message.

But in the second paragraph, if the next byte comes before the 3.5 character times, I consider it part of the message I just threw out in the previous paragraph?

I'm so confused... What do other people do?

Chris Robson

 

> I'm so confused... What do other people do?

I agree, this is confusing, and also largely irrelevant since most serial interfaces aren't going to let you distinguish between 1.5 and 3.5 character times anyway.

What I do is configure the serial interface to notify me after a break of at least 4ms (this is 3.5 character times at 9600bit/s).
The bytes received before this break constitute the message which will either be valid or invalid depending upon the number of bytes received and the CRC.
For other baud rates, adjust the silent interval accordingly, whereby an interval slightly longer than necessary shouldn't cause you any problems.

--Maurus

 

Please check the http://www.control.com archives.

As has been pointed out many times, if you really DO succeed in such tight timing as discarding anything with a 1.5 char gap, your product will only work with a small % of the other products in the world. Many fat GUI computers acting as master/client cannot send out a stream of bytes so
flawlessly.

If you are creating a slave, you'll need a user-definable timeout or idle gap that can be set as high as 50-char times or even higher. Use the 3.5 as a default - if you enjoy support calls as people call to ask why your product gives them a 40% error rate and your competitors have 0%!

It is far better to set this to a BIG number and then use knowledge of the message being received to estimate it's length as it is received. Then you can detect end-of-message with NO delay, yet still accommodate master/clients that add gaps to the message due to sloppy interrupt processing.

best Regards
Lynn August Linse, [email protected]
IA Firmware Specialist, Digi Int'l (www.digi.com)
Board Member, The Modbus Organization (www.modbus.org)
26741 Portola Pkwy, Suite 1E #242
Foothill Ranch CA 92610-1743 USA
Ph/Fx: 949-916-1524 or 949-212-5802

 

> I've been reading the "Modicon Modbus Protocol Reference Guide",
> PI-MBUS-300 Rev. J that I downloaded off of MODBUS.ORG. And have
> come across some conflicting information ... about timing.

This is a topic that gets pretty regular and thorough treatment in this forum. I recommend reading the following threads from the past year or so:

http://www.control.com/1026151416/index_html http://www.control.com/1026160048/index_html http://www.control.com/1004462967/index_html

This thread discussed strategies for handling Modbus timing, but has some statements that bear directly on your question near the end of the thread.

http://www.control.com/1003330164/index_html

And this one from the Spring of 2000 includes a discussion of the rationale behind the timing spec and issues of compatibility between more and less rigourous implementations of it: http://www.control.com/952698879/index_html

Happy reading,

Greg Goodman Chiron Consulting

 

The reference to 1.5 character times is usually regarded as a typo - but it's strange that it's never been corrected.

Frank

--
Wingpath Limited
Custom software development in Java and C/C++ for Linux
http://www.wingpath.co.uk

 

> 3.5 as a default - if you enjoy support calls

I've used 3.5 times for the slave with Fisher-Rosemount and Honeywell masters, plus plenty of less well known masters. I've yet to receive one support call.

> It is far better to set this to a BIG number
> and then use knowledge of the message being
> received to estimate it's length as it is
> received.

This is fine if you want to process each incoming byte individually. This can be not only time-consuming (requiring many cycle-times on a PLC), but also more software intensive.

I do however accept your point that it might be preferable to increase the silent time above the minimum 3.5 character times. It really depends upon the master being used and the overall speed requirements if a large number of different read and write requests are being made by the master.

--Maurus

 

The way I understand it and implemented my slave is as follows:
1. After 1.5 char time has expired with no receiver activity, assume the incoming message to be complete and begin processing it.
This is the criterion for detecting the end of a message frame.
2. After 3.5 char time has expired with no receiver activity, assume the next byte to be the first byte of a new message.
This is the criterion for detecting the beginning of a new message frame.
3. Bytes received after the (presumed) end of the previous message frame but before 3.5 char time of silence expires should be discarded.

Note: If a message is incomplete (due to delayed bytes), a message frame (CRC) error will be detected during processing and the message should be flushed.