Modbus 3,5 byte length at beginning and end of ADU

[lisek_lichu]

Hello,

Can somebody explain me how we handle receiving this 3,5 length at front of ADU and at end of ADU?

if master sends request, at the beginning minimum 3,5 Tz should be sent, so how we handle receiving this by slave?

In RDA interrupt first byte we receive is used as address to which slave message is sent so where we receive or calculate 3,5Tz?

Or this time is only logical 1 instead of zero?

thanks for help

[FvM]

t3.5 is a required idle time between meassages. A slave should observe it in two regards;
- keep the idle time before answering to a master's request
- reset the receive state machine if a pause of more than 1.5 character time is detected in received data

The CCS provided MODBUS example code implements both requirements by a timer.

[lisek_lichu]

hi,

thanks for answer. I see that during this 3,5Tz nothing is received by slave because line is in logic one during this time.

But how we handle this:

[FvM]

Apparently the 1.5 character frame timeout isn't correctly implemented in some modbus.c versions.

[Ttelmah]

Two things. First, 'Modbus over serial' doesn't have it....
On this format, the time-out's are left much more 'open'. Up to several seconds!....

Then the problem is that the driver supports modbus over serial, and modbus RTU. RTU, is meant to have the <3.5 character time assumption, to ensure the state machine restarts in the 3.5 character gap. Then there is also meant to be a 'message timeout' beyond this (which would need to be added by the user resetting the interface if a message has not been received after several seconds).

The 'official' RTU spec on this timeout, is one of the most 'ignored' parts of modbus, because it has to be... You have the problem that the modems etc., may introduce pauses. The comment made by Lantronix in their user guide, 'says it all':

"Character Timeout (10-7050 msec)
This sets the timeout between characters received. Official Modbus/RTU
defines a 3.5 character time-out, but complex devices have various
interrupts that can cause 5 to 10 character “pauses” during transmission.
A safe value for general use with Modbus is 50 msec. Note: Setting this
value lower than 50 msec will not improve performance and may even
make performance worse."

So their 'timeout', won't even go down to the 3.5 character time value, let alone 1.5 character times!. This is the way CCS have implemented things as well.

The only times I've had to 'tweak' the CCS implementation, in this regard, when using it, to receive from other kit, has been to increase the timeout over some links.

Best Wishes

[FvM]

The official MODBUS is clear in this regard, I think.

MODBUS RTU format specification in "Modbus_over_serial_line_V1_02"

[Ttelmah]

Totally agreed.
However it doesn't work, and every unit I have used with Modbus RTU, has extended it, or allows you to extend it.
The problem is that it only works if you are using modbus RTU over a direct wire link. Few process control application actually have this being the case....
As I said, it is one of the most 'ignored' parts of modbus.

Best Wishes

[FvM]

I see the problem. The idea of t1.5 is to allow a safe recover from transmission faults and resynchronization
to next message start. If you increase the timeout above t3.5 (or the actual inter-message delay) recover
may take long on a busy bus.

A number of fieldbusses involve real-time requirements for the serial interfaces. MODBUS isn't the worst
in this regard.

[Ttelmah]

Very much The Truth....

The only reason I met this, was quite a while ago, I wrote my own Modbus RTU slave on the PIC, and was 'scrupulous' to follow the timings. Worked fine in the lab, but on over 90% of real systems, it gave problems. Ended up having to extend the timeout.
The 'solution', was to only use timeout for long breaks. Instead look at the data stream, and if the packet is unrecognised, switch to a 'search' mode and look for the start of packet.

Best Wishes

[lisek_lichu]

Ok thanks a lot for answers,

In my system everybody uses exactly Modbus_over_serial_line_V1_02 spec so i will try to do it like it is described in this document.

[Ttelmah]

No.

The simple 'time' criterion for a packet failure has to be extended.
Instead use a data criterion, based upon:
1) data arriving that is incorrect.
2) framing error on the bytes.

The simple 1.5 byte time timeout, only works successfully with direct wire links over short runs. As soon as data goes 'through' another transport medium (modem, packeted over ethernet etc.), the medium starts introducing time delays that can incorrectly trigger the simple timeout.

Best Wishes