3.7.x sync client loose inter char timing?

[MAKOMO]

Now that the strict keyword parameter got removed, what is the recommended method to set the serial connection to loose inter char timing.

Several users of my Artisan app are reporting that communication fails with the latest app version where I upgraded to pymodbus 3.7 and thus had to removed the strict=false keyword. It seems that with some serial devices using some serial drivers (at least on Windows) pyserial seems to fail to deliver all received data to pymodbus which in turn complaints about having received not the expected number of bytes.

For now I added the following line after the connect() call to reset the pymodbus default strict timing to the default pyserial loose timing.

self.master.socket.inter_byte_timeout = None

This seems to have fixed the communication errors for those users.

pyserial (as well as some usbSerial converters and their drivers) seems to have some issues with that inter_byte_timeout, at least on some platforms. See pyserial/pyserial#88

[janiversen]

Pull requests are welcome.

[MAKOMO]

My pull requests would just add that keyword parameter back reverting your commit. This might be unproductive.

[janiversen]

Well you suggested something else.

Pymodbus adhere to the standard so there are no need for the "strict" keywords. When sending it is always "strict", when receiving we can relax.

[MAKOMO]

This is about receiving and the issue (not sure pyserial allows to treat sending and receiving differently w.r.t. inter_byte_timeout) seems not to be caused by the external MODBUS server, but by a combination of the RS485 to USB hardware, the serial driver, Windows and pyserial which fails to forward the correctly send data from the device to pymodbus if this inter_byte_timeout is set to anything but its default. As fixing pyserial seems to be difficult to impossible (thus there is a PR that fixes part of this issue), my suggestion would be just to add the flag back such that an app using pymodbus can set this to "non-strict" on Windows to enable communication in such situations. This seems to be the reason why that flag was initially added (a work-around a pyserial issue).

[janiversen]

And what is wrong with just adding your suggestion (which btw I assume is for sync). Fixing async should be done in our pyserial amendment.

[MAKOMO]

Nothing. Just that users of the pymodbus lib will need to know that they need to add this in case they are on Windows and are working with such problematic hardware. Maybe this should be added to the doc somewhere as a note? Yes this I am using the sync client here.

[janiversen]

I just checked the old code (serial.py):

If self.strict:
                self.socket.interCharTimeout = self.inter_char_timeout

strict was default, so setting it to false, means the interCharTimeout will not be set....BUT in 3.7.2. it is also not set !!

so your fix seems to fix something else, meaning I do not think that reverting 6ca1b04, would make any change for you. Seems your problem is around inter_byte_timeout, which was introduced later.

[janiversen]

Seems there was multiple changes, hold on.

[janiversen]

the problem is more likely fe809d9, which added inter_byte_timeout

[MAKOMO]

Yes this must be the change causing this issue. Bad, now one of them claims that also with my hack above his device is not communicating any longer with my app. Maybe there is another change breaking it for him. He is using an Arduino with corresponding lib. I was not successful in getting him to send me meaningful log files. I have myself not the hardware nor a Windows installation to investigate this myself so I will have to pin pymodbus to v3.6.9 to resolve this for my app and wonder why similar problems were not reported (yet) by anybody else. Sorry for not being more helpful on this one.

[janiversen]

It is very new to me, that pymodbus runs on Arduino...I tried about 2 years ago, and did not succeed.

[MAKOMO]

Sorry for the confusion. The slave is running on an Arduino in this case, but not using pymodbus but running Modbus-Master-Slave-for-Arduino.

The issue with this turned out to be not related to strict vs non-strict inter char timing, but to the fact that the Arduino restarts on serial connects. That takes a moment (about 1.6s in this case) thus the first few requests the sync client of pymodbus receices null. The sync client before 3.7.x did offer the option retry_on_empty. With this the sync client did retries in this case and succeeded eventually. Now with pymodbus 3.7.x there are no retries anymore with the sync client. Realizing retries on the app level fails here two as pymodbus closes the port on error thus the app needs to reconnect which triggers another reboot of the Arduino. The initial solution I implemented was a user configurable delay between the connect and sending the first request which kind of worked. However, by now I moved the Artisan app finally to the async pymodbus client which offers retries and all is good again (also the issue with the inter char timing on the other slave seem to be resolved by moving to the async client).

[janiversen]

Thanks for the explication. the async client/server is where all development is focused, the sync client is purely maintenance, so changing is a good thing.

FYI, mid-term the sync client will be nothing more than an interface class and all internals will be async.

[alexrudd2]

Several users of my Artisan app

This one? https://artisan-scope.org/about/ Cool app!

I believe this is the discussed issue: artisan-roaster-scope/artisan#1694

[MAKOMO]

Thanks! Yep this is the issue. Sometimes those discussions are a little difficult as the users are general not very technical. Getting a proper log to find out what is exactly going on is often difficult. So one needs to guess a lot.