Timout Issues Again

[zerox1212]

I just grabbed the latest modbus_tk and updated to pyserial 3. There are still issues with RtuMaster._send().

The fix resulting from https://github.com/ljean/modbus-tk/issues/57 is not a complete fix.

https://github.com/ljean/modbus-tk/pull/58 appears to be fine if you are talking to a single slave, but if you have multiple slaves to read the library breaks. For example if you have four slaves, it will probably read slave 1 and 3, because 2 and 4 will fail immediately, and that delay for failure is enough to let the next send request work.

At the moment I don't know how to fix it besides putting a fixed delay time in _send() again. If anyone knows what the modbus spec is for the delay between messages let me know. If someone has an idea how to fix it I can test.

As far as I can tell the flow should be like this: send > wait for timeout, if message recieved, parse > after read is complete, wait a short time before initiating another send

[zerox1212]

So I looked into it a bit closer. In the end it seems to be my slaves that are the primary issue (they need a lot of 'idle' time between requests, otherwise they don't respond).

However I discovered a few things and I will probably make a PR.

1. RtuMaster class init does not set timeout correctly in my opinion. It uses interframe as a timeout, but this should actually be a fixed modbus timeout (such as 1 second). This is because the library is counting on the pyserial library to find out if a timeout happened. I could not find any timeout request code. If you want to test it, set master.set_timeout(None) and watch pyserial block forever waiting for a read. It has to be None, the number zero doesn't work.
2. Seems char_timeout was deprecated. There isn't any code issues, but just wanted to know that setting a char timeout will actually set the inter byte timeout.

If I get some time I will clean up RtuMaster so it's more clear what is happening.

[rdpoor]

I came here to study how modbus-tk handles master/slave packet exchange in RTU mode, and I agree that this is a problem:

[RtuMaster] uses interframe as a timeout, but this should actually be a fixed modbus timeout (such as 1 second)

The interframe timeout is not the same as a slave reply timeout, and in fact 3.5 byte periods is often too short for a slave to respond (as you've observed).