What is Silent Interval? What is the significance of 3.5 character times of Silent Interval and 1.5 character times the Silent Interval in Modbus RTU mode? How Silent Interval is generated and detected Silent Interval? I am using 8051 On-chip UART

 

Any case where the device may be operated multidrop requires careful adherence to the '3.5 character gap' timing requirements for a message, which are as follows:
Within a message, from the slave address byte to the last byte of the CRC16, there must not be a hesitation between characters longer than 1.5 character time.
Between messages, from the end of the stop bit of the CRC16 of the previous message to the beginning of the start bit of the next message, there must be a 'line idle' condition of at least 3.5 character times.
These time requirements are essential in order that a multidrop device can unambiguously distinguish a 'fragment' of a message sent between two other parties on the line from the start of a valid message addressed to himself. A slave must not assume than an incoming request packet is valid unless it satisfies:
1. The 3.5 character gap line idle time preceding a valid message
2. The correct slave address in the first byte of the message
3. A valid length of incoming message (no message can be less than 4 bytes or greater than 256 bytes) before seeing the terminating 3.5 character gap
4. The correct CRC16 checksum for the incoming message

Regards
Brian
www.wittecom.com

 

"Silent Interval", sounds like a good name for a movie. If it's like the Silent Interval in the MODBUS Protocol, it won't make much at the box office.

The Silent Interval in the MODBUS Protocol refers to a method to determine the start of a new message. It is mostly used in reference to the RTU mode. The ASCI Mode uses a start of frame, a ‘colon’ ( : ) character (ASCII 3A hex), to indicate a new message.

It depends on how close your driver (the code you are writing) is to the hardware (Serial Communications Chip) as to where or not you can determine the minimum Silent Interval between messages. In PCs the data stream is buffer on both the transmit and the receive. This makes it difficult to determine the timing between messages.

Generally the Silent Interval is not important in that there is a large time between messages. The Master request and the Slave responds, usually means that there is sufficient time in both directions to distinguish between messages. Also the Slave will only respond to its Slave Address.

The sender should send the characters as fast as possible for the entire message [The entire message frame must be transmitted as a continuous stream]. At the end of the message the sender should insure the another message is not sent for at lease 3.5 character times [Following the last transmitted character, an interval of at least 3.5 character times marks the end of the message. A new message can begin after this interval]. The 1.5 character time is the maximum time allowed between received characters. If it is exceeded then the receiver would flush the incoming character and assume that a new message is started with the next message [If a silent interval of more than 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].

Some times this is not practical. Many driver developers ignore these rules.

It sounds like you are close to the hardware. You could control these characteristics in your driver program. I would suggest making them optional with parameters to control the delays. This would make your driver more general purpose. You should also provide control of common hand shaking lines with parameters to control their timing.

[email protected]

 

The specification says that you must not *exceed* 1.5 character times between the bytes of a message, I don't see any reason for this. Either you are at the end of message or you are not. It would be a good a practice, however, to send your messages as a continuous, uninterrupted stream. The spec does not say to place
a 1.5 character delay between bytes.

Some delay is required between messages though. Modbus
RTU is a binary protocol, no special character is reserved to indicate the beginning or end of a message. A slave would not be able to reframe the masters requests without some delay between messages. Another reason for this is to allow multidropped slaves to efficiently monitor the master. With the delay, the slave only has to look at the first byte after a silent interval to see if the message is for him, he can ignore the other serial port interrupts. You'll have to do this timing in your program.

I was much too short in responding to your previous question on the CRC and LRC.

There are some good reasons not to put a CRC on a Modbus ASCII message. First, no other Modbus device would be compatible with yours if you did. Second, the CRC is a 16 bit quasi-random number. As such, one of the two bytes in the CRC calculation would pop up as the ":" character in one out of every 128 messages. But the ":" character is
reserved in Modbus ASCII to designate the beginning of new message. You should see the confusion this would cause. Third, if you choose to using ASCII protocol you have stick to the ASCII character set, a 16 bit CRC will generate two ASCII characters only 1 out of 4 times ( two bytes and the ASCII character set includes 128 of
the 256 possible 8 bit byte values). Half the bytes wouldn't go anywhere over a 7E serial line.

There is a potentially misleading statment in the "RTU Framing" section of the "Modbus Protocol Reference Guide" second paragraph, first sentence. ( see www.modicon.com/techpubs/TechPubNew/PI_MBUS_300.pdf )
Modbus RTU protocol is binary (better yet, unformatted), *NOT* hexadecimal. There have been a few posts here on the subject of Modbus where the programmer is trying to format his RTU messages in ASCII-Hex and getting nowhere.

Maybe one of the Schneider or Modbus.org folks here can help with getting that sentence in the spec reworded ??

JK jkirsch at macroautomatics .com

 

No reason to send a CRC 'as is' on Modbus ASCII; one could just as well convert the CRC to 4 ASCII characters, and all of the above problems disappear.

 

Rob,

You might be correct about the second and third problems I raised (not the first one though).

The CRC-16 was designed to hunt down bit and byte errors in a binary stream and it has a certain ability do this. I suspect the statistics get muddled up when you reformat the CRC in ASCII.

Maybe not, but without the math to back this up and as a practical matter, I think its best just to follow the specification.

jk

 

Actually CRC16 is used to detect errors in a given length packet of data. The correction consists of throwing the packet away and requesting a resend. It is redundant with TCP, but I agree that it needs to be there, not just for the spec, but in an application where the transport is transparent, the receiving end will expect it and throw away packets that fail the check. If you write both ends, this won't be a problem but the whole idea of a protocol is to be consistant and predictable. I've scratched my head over their implementation, and there is a lot not covered in the spec, but at least there _is_ a published, authoritative spec. to work from.

Regards

cww

 

Agreed, but there are some TELECOM issues here. Take parity for example. I am not a TELECOM expert, but there is more to turning that parity bit on or off than you would get from a completely software based error correction algorithm. Likewise, I was trying to express my uncertainty ( and ignorance ) about whether or not reformatting a binary CRC16 into ASCII Hex maintains the statisical validity of the binary CRC attached to a Modbus/RTU message. Not a big deal, I was just hunting for some info on this.

JK

 

<snip>
> It sounds like you are close to the hardware.

Speaking of hardware: Is the 485 network being actively driven during the 3.5 character silent
intervals? In other words, if a slave is replying to a query, does it enable its' 485 driver for 3.5 characters before sending the address, etc, and then again after sending the CRC bytes?

Thanks!

 

The RS-485 lines cannot be left floating. Your system should have some form of line biasing that holds your RS-485 in an active state.

Should you actively hold the line silent for 3.5 char? I won't bother. If your bias is correct, this has no value. If another node starts to transmit while you hold the line idle, he'll win out and cause bits to be detected. So to me this is wasted effort.

Best regards

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