A timeout, by definition, is the master waiting for a response after sending a request (i.e. not transmitting anything more on the bus) and not receiving a response after a given amount of time (typically in the hundreds of milliseconds range). The 3.5 char time is far smaller than the timeout time of the master. Therefore, it is impossible for there to be less than a 3.5 char silence time on the bus while the master is waiting for a response to its request. Note that a Modbus RTU master must send only one request at a time and wait for the response or a timeout.

If the slave were violating the Modbus timing, for example transmitting bytes in its response with more than 3.5 character time between them, this could cause the master to receive several partial packets instead of a single response packet.

Jschule, Request/respond with interbyte time less than 1.5 char is a Modbus violation at Master or Slave, slave will not respond to this type of Master request which would lead to timeout, Master will not understand this type of Slave response and I guess will end as Timeout. I have seen two Master requests, with timeout in between, and as you are saying is impossible because most of comm settings does not allow timeout=0, I am thinking on, less than 1.5 char in the last two bytes of Master request to slave, that may explain this timeout, or timing issue between Master and slave in their clocks.

 

Jschule, Request/respond with interbyte time less than 1.5 char is a Modbus violation at Master or Slave, slave will not respond to this type of Master request which would lead to timeout, Master will not understand this type of Slave response and I guess will end as Timeout. I have seen two Master requests, with timeout in between, and as you are saying is impossible because most of comm settings does not allow timeout=0, I am thinking on, less than 1.5 char in the last two bytes of Master request to slave, that may explain this timeout, or timing issue between Master and slave in their clocks.

Just to confirm, you meant greater than here instead of less than, correct? The spec states that if a silent interval of more than 1.5 character times occurs during a frame transmission, the frame is deemed an incomplete message and should be ignored.

Yes, if the master's request is violating Modbus timing requirements and the slave receives a request that has more than a 1.5 character time silent time between characters, the slave may declare a partial message and the master's request will timeout because the slave will not respond. However, if the slave's response has more than a 1.5 character time silent time between characters, (ideally) the master should report this as an invalid packet or checksum error, not a timeout error, since it did receive something.

Perhaps if the master's CPU is doing some intensive operations (and is poorly coded), this could theoretically lead to gaps in its request transmissions. Again, though, I really believe that this type of timing violation is unlikely to be the cause of your issue. I recommend investigating the potential causes of timeout issues I mentioned in my post #17.

 

SCADA developer here. As for masters, timing is of no interest to me. I send a request, wait for an answer. Usually there's a Moxa Nport between me and a serial slave. I use UDPs to talk to NPort (works great for redundant servers; no TCP glitches, if a packet gets lost, no problem, we resend).
As was said, we have a state machine, so as long as slave sends data within configurable time limit, we accept it and process. It may be all in 1 UDP packet ...or every char in a separate one.
There are serial communications over GPRS with variable latency - we had to enhance timeout to several seconds to handle them! (we use Moxa OnCell).
There are many other parameters to configure when talking to various slaves: endianness (multiple "little" definitions for 4-byte variables), various definitions of strings (1 or 2 chars per register), even 1-byte registers and variable-size-register abominations exist out there!