Response time requirement for Modbus RTU Master

Hi,

I would like to understand whether there is any strict timing requirement for when the Modbus RTU Master should start processing responses from the Modbus Slave ,once after the request is send out.

I know the inter frame delay between 2 modbus RTU Frames should be minimum t3.5 delay for baud rate less than or equal to 19200kbps and its should be 1.750ms for all baud rates above. Does it mean that the ModBus RTU Master must process any response that comes in the serial lines after this delay time of t3.5 or 1.750ms? Can The Modbus RTU master be termed as non-compliant if it does not meet this requirement?
 
I don't believe there is any maximum timing requirement for when a master should start processing a response. Although, I can't think of why you would want to artificially delay processing a response.

As you've stated, the spec says that the silent interval must be at least 3.5 character times. As the master is in full control of when requests are sent on the bus, I don't think there would be any problem with waiting longer than this (since the bus will just be silent because no slave can transmit anything without the master first sending it a request).

It is common for Modbus Masters to have a setting to delay the transmission of each of its requests, after receiving a response or timing out. This is typically called Poll Delay, Request Delay, Scan Rate, etc. However, this setting does not delay when the master processes a response.
 
jschulze - I agree.
Consider serial communications transmitting Modbus queries over radio and traversing a couple of repeaters. The query could take a few seconds to get to the destination and the response would take a similar amount time. Check out page 100 on the attached Modicon Modbus Protocol Reference Guide
Document: (modbus.org)
 

Attachments

Thanks for the response. My actual concern was that in my case the Modbus RTU client was nor processing the responses when the Slave responded back within a time gap of 100ms ,after the request was send out(baud rate in the scenario is 9600). Could we term the client as non-compliant in this case?
 
Maybe the Modbus Client already considered the request to be timeouted if the configured timeout is too short? In our MODBUS Client implementation, we have several timeout-related parameters:

Wait First TimeoutDelay after sending the request before reading the response.
Wait TimeoutTimeout between reading the reply.
Max. Wait RetryThe maximum number of retries of the reply reading.

If the „Retry Count“ parameter is set to 1, the response doesn't come in time, the request won't be resent, but it will be considered to be timeouted.

I remember having problems with this when we started to do Modbus communication using the GPRS network (via OnCell Moxa devices). This caused non-deterministic link latency (sometimes, the response came hundreds of ms later), so the timeouts had to be increased. Also, we implemented the "Check Receive Length" parameter, to (at least partially) protect from a scenario when you send a request, don't receive anything, send another request, receive an answer to the first request, parse it, and boom - you have values assigned to wrong measured points :) Plus, we increased the timeouts, so the total timeout while waiting for a response, would be several seconds...

 
Thanks for the response. My actual concern was that in my case the Modbus RTU client was nor processing the responses when the Slave responded back within a time gap of 100ms ,after the request was send out(baud rate in the scenario is 9600). Could we term the client as non-compliant in this case?
Is this Modbus communications over ethernet and then through an ip-to-serial converter?
 
Top