Modbus RTU message frames

K

Thread Starter

Kelly K Moni

Hi

I am developing an application using Modbus RTU format. I would like to know how to find out the RTU message frame separation time.

I read in the documentation that the RTU message frames are separated by a silent interval of at least 3.5 character times. How do you define the character time, is it the time taken to transmit one byte?

I am not clear about how to calculate the message frame separation time. Please advise, any comments or suggestion is much appreciated.

Thanks
Kelly
 
The character time is the time that it takes to send one byte. This includes start bit, parity bit, and stop bit(s). The modbus spec says for NO PARITY to force the parity anyway. This is actually called MARK parity and people should understand this. It also appears to look like two stop bits, so it really doesn't hurt anything. They did this so that ALL byte frames are the same size so you do not have to dynamically calculate the number of bits if the parameters are changed.

Also, for higher data rates, some idiot thought it would be cute to make a TIME definition instead of a character-time definition. This, however, is not in the modbus specification, so I consider it NON STANDARD. (ie: character timeout = 750us, inter-frame delay = 1.750ms) If one cannot resolve the timing according to the modbus specification, then he should not even attempt the data rate, that is my opinion.

In my products, I allow the user to tweak all timing parameters based on character-times, and have an override dip switch to force it to a strict modbus standard.
 
Character time is the total time for all bits that are sent per character. For example, with 1 start bit, 8 data bits, no parity and 2 stop bits at 9600 baud, the total character time is:

11 bits x 1sec/9600 bits = 1.14ms

This means the silent interval must be at least:

3.5 x 1.14ms = 4.01 ms

Hope this helps

[email protected]
 
L

Lynn at Alist

Up to you, but in my code (working fine for nearly a decade) I've always first tried to estimate message size based on the bytes being received. For example if you are a slave device and you have 2 bytes already and the 2nd byte is 0x03, then you know you should be receiving 8 bytes. If after 8 bytes, the CRC is zero, then you guessed correctly and are done. with no added delay.

Assuming you are an "end device" (slave or master) and not a bridge, then you have a fixed list of commands you support. It is easy to create a parsing routine to know how much data has come and see if you can guess the length.

The problem with 3.5 chars is some high-level language tools on large computers cannot send/receive data consistant enough to satisfy this. So the Master may accidently "pause" for 4 character times in the middle of sending a message because of some combination of interrupts. If you follow the rules strictly, you could have a high % of errors.

You still need an "inter-character timeout", but I start with a default of 50msec and let users change it up or down. Even if I expect 8 chars but after seeing 5 I have this timeout, then discard the message.

Best regards
- LynnL, www.digi.com
 
B

Bill Clemons

At 9600 baud, RTU:
Silent Interval Time (ms) = 3.5 char * 8 bits/char * 1 sec/9600 baud * 1000 ms/sec ~ 3 ms
 
K

Kelly K Moni

Thank you guys for all your input. Couple of days there was no response, I was thinking how to figure this timeout. I sincerelly appreciate all your comments.

I do have a follow-up question with respect to Lynn's comments: "For example if you are a slave device and you have 2 bytes already and the 2nd byte is 0x03, then you know you should be receiving 8 bytes. If after 8 bytes, the CRC is zero, then you guessed correctly and are done. with no added delay"

I understand for function code 0x03 (second byte) the total number of expected charachers including CRC is 8 bytes. Can you please elaborate when u mean when you say "If after 8 bytes, the CRC is zero, then you guessed correctly and are done. with no added delay"

I am writing the Slave side and this is my first Modbus application, so I am not very familiar with the details. Also the application is a micro controller application and not a PC based one, so that adds to my complexity.

Thanks in advance for your comments.
Kelly
 
Simple, if you calculate the CRC for the entire packet, the CRC is zero. Often times it is simpler to just compare the calculated CRC with the ending CRC.
My buffer routines automatically calculate the CRC anyway, so when I stuff the ending CRC bytes into it (entire packet), the buffer's CRC becomes zero.
 
L

Lynn at Alist

Sorry, this is probably a "bridge" detail. In your slave case, a function 0x03 will be 8-bytes. I guess I always think of that double-check for CRC and "delay" if not zero because as a bridge we can never be sure some idiot vendor hasn't overloaded the 0x03 function to use non-standard format when their Master talks to their Slave. So if after the "guessed" size we don't see a zero CRC we fall-back to the char timeout method just in case they tacked a few extra bytes on. So we'll happily forward a 0x03 poll with 20 bytes of command if the CRC is valid after all 20. I guess that's what a bridge should do - not enforce rules needlessly. Could be a nice religous debate, no?

Since you are a pure slave ONLY supporting standard func 0x03, once you see the 8 bytes you are done. A bad CRC is a bad CRC - you won't be expecting any non-standard extention to the spec.

- LynnL, www.digi.com
 
K
Now I understand. Thanks Max & Lynn for the clarification.

This board is very useful, since I am new to Modbus protocol I am learning a lot through this board. Thank you guys!

Thanks
Kelly
 
L

Lynn at Alist

Yes, but make sure noone takes the short-cut of saying "when CRC=0, message is done". I've heard from a few embedded programmers over the years who've tried that & learned the hard way it doesn't work. Nothing stops the CRC from being zero several times during a continuing message. With only 65,535 possible values, the partial CRC can be zero after any number of bytes are received.

- LynnL
 
You already have some answer but I give my part of solution since I work on the same soft.

The time depend on the trnsmission rate.If you work on RTU mode you must transmit 11 bits and if you work on modbus rtu you must transmit 10 bits for one word. If you define 19200 b/s.

the time to transmit is (1/19200)*11 if you are in rtu mode. after that, you know that only 1.5 time the time to transmit can separate two word. Starting from here, you count with a timer two time the time to transmit one word. If within this time a word come, there is a problem of transmission and you must wait 3.5 time the time to transmit without receive a word and all the word received MUST be ignored. In the other case, the trame is completed and you can treat the information.

That's all
regards,
 
Top