3.5t timeout while transmitting

[Giampaolo Bellini]

Dear all

I'm totally new to libmodbus... so maybe this is a stupid question :D

I would like to know if the latest git library takes care of the modbus 3.5t timeout while transmitting frames... 

sometimes I got a timeout from the library while polling my device for data, and looking at the signals I discover that the incriminated frame was transmitted by the PC before the 3.5t timer expires...  so my dsPIC-based device discard it...

and I doing something wrong ? 

   thanks a lot

               Giampaolo

[Browny]

Hello,
currently I'm studying the libmodbus and facing an analogical problem: How does libmodbus in serial mode achieve the requirements for the MODBUS Message RTU framing?
This means the silent interval of at least 3.5 character times and the transmission of a message frame as a continuous stream of characters without a silent interval > 1.5 characters between two characters.

Maybe someone can explain us the libmodbus timeout handling...

Cheers,
Browny

[Giampaolo Bellini]

Hello Browny

  I've not dig into the source code in order to check if/how libmodbus takes care of the 3.5t timer... but I had to add a delay (2ms circa for speed >=19200 bps) after each frame transmitted by my (libmodbus-based) master in order to ensure correct timings (eg silence time) between commands...

      Best Regards

             Giampaolo

2012/10/29 Browny <mr.ernes...@gmail.com>

[Browny]

Hello Giampaolo,

thanks for the reply. This could confirm my suspicion that libmodbus itself does not achieve MODBUS timing requirements. Maybe Stéphane Raimbault can provide some details about this issue.

Best Regards

Browny

Am Dienstag, 30. Oktober 2012 11:53:31 UTC+1 schrieb iw2lsi:

Hello Browny

  I've not dig into the source code in order to check if/how libmodbus takes care of the 3.5t timer... but I had to add a delay (2ms circa for speed >=19200 bps) after each frame transmitted by my (libmodbus-based) master in order to ensure correct timings (eg silence time) between commands...

      Best Regards

             Giampaolo

2012/10/29 Browny

Hello,

[Stéphane Raimbault]

libmodbus has never respected the famous t3.5 delay. Years ago when I
wrote first version of libmodbus I want to achieve very fast
communication in RTU, in my case, this delay was the bottleneck (and
t3.5 for 115200 bps is just stupid!, I think Modbus protocol was
designed when there was no such speed :) so I just removed it and I
never need to add them since.

Extract from MODBUS over serial line specification and implementation
guide V1.02 (2006):

The implementation of RTU reception driver may imply the management of
a lot of interruptions due to the t1.5 and t3.5 timers. With
high communication baud rates, this leads to a heavy CPU load.
Consequently these two timers must be strictly respected when the
baud rate is equal or lower than 19200 Bps. For baud rates greater
than 19200 Bps, fixed values for the 2 timers should be used: it is
recommended to use a value of 750μs for the inter-character time-out
(t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

So we can add an API to add this behavior to libmodbus:
modbus_apply_interframe_delay(ctx);

Feel free to propose a better name...

Browny and Giampaolo, why do you need this delay (device, adapter, etc)?
Do you need to define a specific interframe-delay?
Or something dependent of bps?

Stéphane

2012/10/30 Browny <mr.ernes...@gmail.com>:

[Giampaolo Bellini]

Hello Stéphane

 first of all, thanks a lot for your great job... I'm using it under linux&windows and it works like a charm :D

So we can add an API to add this behavior to libmodbus:
modbus_apply_interframe_delay(ctx);

Feel free to propose a better name...

for me it's fine... but I'll add the delay value... this way one can reduce or increase the default value if there are one or more slaves that require special delays...

 

Browny and Giampaolo, why do you need this delay (device, adapter, etc)?
Do you need to define a specific interframe-delay?
Or something dependent of bps?

I need it because without this delay my dsPIC-based slave was not able to correctly detect when a frame is directed to itself or to another controller of the modbus chain... it's really difficult that the data transmitted or received from a slave incapsulate a valid frame (address, command, data & checksum) of another slave... but... it could happens...and the 3.5t is the only way for a slave to detect & prevent this problem.

Best Regards

         Giampaolo

[Browny]

I think we "need" this delay to meet the MODBUS specifications and to reduce communication problems when connecting different MODBUS devices with libmodbus-based devices.
The idea of using fixed timings when using baudrates > 19200 is good and should be documented when it will be implemented. When using baudrates <= 19200 the delay times should be calculated depending on the used baudrate (e.g. 9600 Baud, 10-bit mode, T1,5 = 1563µS). I would really appreciate if this is possible.
But I was mostly wondering how this real-time requirement is realized on a non real-time (linux) operating system.

Best regards,
Browny

P.S.: Thanks for the reply and the great work on the libmodbus, Stephane.

[Stéphane Raimbault]

2012/11/2 Browny <mr.ernes...@gmail.com>:

> I think we "need" this delay to meet the MODBUS specifications and to reduce
> communication problems when connecting different MODBUS devices with
> libmodbus-based devices.

I only follow Modbus specifications when it makes sense. It's
certainly why this point has evolved from the original Modbus
specifications (the recommandation about fixed timings is new).

You only need this timing if your clients are bugged.

> The idea of using fixed timings when using baudrates > 19200 is good and
> should be documented when it will be implemented. When using baudrates <=
> 19200 the delay times should be calculated depending on the used baudrate
> (e.g. 9600 Baud, 10-bit mode, T1,5 = 1563µS). I would really appreciate if
> this is possible.

Yes, but as previously asked, do you need it (in real life)?

> But I was mostly wondering how this real-time requirement is realized on a
> non real-time (linux) operating system.
>

It's a _minimum_ delay not a deadline!

Stéphane

[Stéphane Raimbault]

2012/11/2 Giampaolo Bellini <iw2...@gmail.com>:

> Hello Stéphane
>
> first of all, thanks a lot for your great job... I'm using it under
> linux&windows and it works like a charm :D
>
>> So we can add an API to add this behavior to libmodbus:
>> modbus_apply_interframe_delay(ctx);
>>
>> Feel free to propose a better name...
>
>
> for me it's fine... but I'll add the delay value... this way one can reduce
> or increase the default value if there are one or more slaves that require
> special delays...
>

What do you think of:

modbus_apply_interframe_delay(ctx, int delay);

delay in ms with special values :
MODBUS_INTERFRAME_AUTO (-1) apply computed timing <= 19200 and fixed above
0 to disable

>>
>> Browny and Giampaolo, why do you need this delay (device, adapter, etc)?
>> Do you need to define a specific interframe-delay?
>> Or something dependent of bps?
>
>
> I need it because without this delay my dsPIC-based slave was not able to
> correctly detect when a frame is directed to itself or to another controller
> of the modbus chain... it's really difficult that the data transmitted or
> received from a slave incapsulate a valid frame (address, command, data &
> checksum) of another slave... but... it could happens...and the 3.5t is the
> only way for a slave to detect & prevent this problem.
>

I see the device reads slave address, think "it's not for me" and
waits for final break before listening again. In this case, libmodbus
analyzes the request to be ready to read again ASAP.

Stéphane

[Browny]

Hello Stephane,

as I understand the specifications T3,5 is a minimum but T1,5 is a deadline.

Best regards,
Browny