Author Topic: Modbus Timeout Error  (Read 19217 times)

Offline mhoneywill

  • Full Member
  • ***
  • Posts: 173
    • View Profile
Modbus Timeout Error
« on: July 29, 2010, 03:56:10 PM »
Hi Mark,

Just thought I'd let you know about a "feature" I'd found in the modbus module, and thought you might want to mention in the Modbus manual.

I have a modbus system running and was trying to tighten up the timeout delay because my targets reply very quickly. I accidentally set the modbus timeout value in the cMODBUS_default in modbis_app.c to the same value as the uTasker TICK_RESOLUTION. This was then causing random suprious comms timeouts, which took some while to trace. I was getting timeouts even when valid data was returned.

Just something to be aware of in the Modbus module, I don't think there is anyway arround this as by definition the resolution of the system is defined by the TICK_RESOLUTION

Cheers

Martin

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3013
    • View Profile
    • uTasker
Re: Modbus Timeout Error
« Reply #1 on: July 31, 2010, 12:17:09 AM »
Hi Martin

The MODBUS module uses SW timers (in fact it uses global SW timer times so that it can have multiple such timers monitoring multiple sessions at the same time). It would not generally be practical to allocate a HW timer to each session since the number can easily become much larger than the available HW timers.

The characteristics of SW timers is that they have a limited, specified resolution - defined by TICK_RESOLUTION. This resolution results in a limit of their accuracy which can also be described as a jitter accuracy when the timer use is not synchronous.

a) Synchronous SW timer use is when a SW timer event (or other event synchronous to the system TICK) is used to start another SW timer. This results in low jitter because a system tick has just taken place, which starts another multiple system tick period.
b) Asynchronous SW timer use has a higher jitter because a timer is started by an event that has no relation to the system TICK. For example starting a timer when receiving a UART message generally has no synchronisation to the system TICK and so could occur at any time between two system ticks (the extremes being fractionally after a system tick has occurred and fractionally before the next system TICK takes place).
The "worst" case is when a single period delay is programmed, whereby the SW timer is programmed to fire when the next system TICK arrives. This can be immediately or up to 1 system TICK time in the future. This worst case jitter is thus 0...TICK_RESOLUTION and improves when the SW timer period is increased - generally X * TICK_RESOLUTION - 1 to X *TICK_RESOLUTION.

This means that when using SW timers to monitor timeouts, a value much be chosen so that X * TICK_RESOLUTION - 1 is never less that the minimum timeout value. Note that a value of X of 1 results in the possibility of the timeout approaching 0! This is presumably what you experienced when you had timeouts even though the system reaction time was low.

The rule is thus to chose a system TICK which allows adequate jitter accuracy based on the equations above.

Of course this is not specific to MODBUS but is valid for any application using the SW timers. I will review the SW timer document to see whether this point is adequately described - also the MODBUS module to see whether a reference to this behavior would be of advantage.

Cheers

Mark

Offline mhoneywill

  • Full Member
  • ***
  • Posts: 173
    • View Profile
Re: Modbus Timeout Error
« Reply #2 on: December 09, 2010, 12:18:18 AM »
Hi Mark,

I'm replying to this document as my point is a follow on from the comments made earlier. I'm using modbus RTU at 115200 baud.

I currently have a TICK_RESOLUTION of 10ms and want to really get this down to a small value to allow for fast modbus responses. I've tried setting TICK_RESOLUTION to 1ms and this seems to have the desired effect for me. I have a few questions though

1. What are the implications of setting a small Tick resolution like this, I presume it is only the overhead of the Tick interrupt service routine and the associated timer handling code.

2. Are there any implications for the Simulator of setting a small Tick resolution?, I know it will not simulate a tick rate this fast but I presume it should still work as before.

3. Am I correct that the modbus Time-out is triggered from the start of the modbus send rather than the point the last byte of the transmitted message is sent? It would seem to be more logical to start the timer from the point the last byte of the transmitted message is sent but this might be more complicated to achieve. This also means that very long messages might easily take longer to transmit than the time-out time.

4. Related to point 3. above when does the time-out stop? if I start receiving a message that is large I might get a time-out in the middle of the received message unless, the no reply time-out has been stopped.

Basically what I want to do is just run the Modbus comms as fast as possible and minimise the inter message gaps. I will also be polling for new devices that may or may not be online hence me wanting to reduce the no reply time-out to a minimum.

Cheers

Martin

Offline phomann

  • Newbie
  • *
  • Posts: 47
    • View Profile
    • Homann Designs
Re: Modbus Timeout Error
« Reply #3 on: December 09, 2010, 01:03:18 AM »
Hi Martin,

If the Modbus slaves are not your design, then they will probably follow the recommendations in the Modbus_over_serial_line_V1.pdf  document.  It recommends that for baud rates greater than 19200 bps a value of 1.750mS delay be used for the inter-frame delay.

You would need to allow a slave this delay to detect the request, some time to process it, then reply. Obviously if you are designing the slaves, you could shorten this.

You could also do the sums to see if ascii mode is more efficient as there are no delays involved, just longer messages.

Cheers,

Peter.


Offline mhoneywill

  • Full Member
  • ***
  • Posts: 173
    • View Profile
Re: Modbus Timeout Error
« Reply #4 on: December 10, 2010, 04:49:30 PM »
Hi Peter,

Thanks for your comments, Both the Slaves and Masters are my design so I have control over the inter frame delay. Indeed the uTasker module has a define to control this specific point.

My questions are related to the specific way the uTasker Modbus module works, from my tests it looks like the Timeout you specify in the modbus parameters, starts from the point the first character is transmitted, rather from when the last character is transmitted. The problem with this is that I may have a very short message where a short time-out would work, but I may also have a large message which also has a large reply which would need a longer time-out.

You can see from the attached trace where the time-out is set at 10ms the time-out seems to be based on the start of transmission, the inter message gap is only 7ms.

My other worry was again with a short inter message time-out and receiving a large packet of data, would the time-out kickin in the middle of the packet being received?

I'm fixed with using RTU comms for other reasons.

Cheers

Martin

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3013
    • View Profile
    • uTasker
Re: Modbus Timeout Error
« Reply #5 on: December 10, 2010, 11:00:43 PM »
Hi Martin

I have understood the timer as the slave timeout. However I would also only expect this timeout to be of importance when there is no slave that responds. If the timeout is long it will not slow the system down when slaves respond - as soon as a slave has responded the master can go to the next job and so must faster operation can be acheived. Only when polling slaves that don't exist will the timeout actually come into play (I think that this is your point).

SW timers are used for the monitoring. These have a resolution equal to the system TICK and so a faster system TICK results in higher resolution. Since there is a TICK interrupt at this rate it increases processor overhead but times down to 1ms shouldn't really be of any problem.
However also remember that the resolution of a time delay is equal to the ((n x TICK) - 1) to  (n x TICK). That is, if you set a timeout of 2 TICKs it can timeout anywhere between 1 and 2 TICKS, inless the start of the timer is actually synchronised to the TICK. When synchronised, it means that the next interval of n xTICKS is started just after a TICK period has ended and so the delay will be much more accurate. Setting a value of 1 x TICK is not advised when not synchronised since it can fire almost immediately.

Since the RS485 mode can recognise the exact end of a TX frame it would also be possible to start the delay there, but unless the resolution is very high and the timeout is very low it shouldn't make any real difference. You always need to account for the longest reception message delay since the timer will only be stopped when this is received without errors (Check sum, etc.). A reception with errors will not kill the timer so that it eventualyl times out to inform that there was no slave answer (a corrupted slave answer is equivalent to no answer).

When simulating, 10ms works well. Maybe you can get it down more but there tends to be a point when the simulator overhead increases so much that reducing TICK doen't make it any faster and even starts to make it slower - best to experiment since it is possible PC dependent too.

Regards

Mark