`TransactionManager` automatically closes connection after consecutive timeouts while polling multiple slaves

[marshfolx]

Versions

• Python: 3.11.9
• OS: Win11
• Pymodbus: 3.15.0

Pymodbus Specific

• Client: rtu - async

Description

I was polling multiple slave addresses (1 - 10) to see how many slaves are connected. After several consecutive timeouts, the connection is automatically dropped, and subsequent requests immediately fail because there is no active connection.

I think this behavior should be disabled by default:

1. The sync client (v.3.12) does not do so;
2. It was a surprise to me;
3. This logic should be explicitly handled by the application.

Workaround

Delete the following code in TransactionManager:

            if self.count_until_disconnect < 0:
                self.connection_lost(asyncio.TimeoutError("Server not responding"))
                raise ModbusIOException(
                    "ERROR: No response received of the last requests (default: retries+3), CLOSING CONNECTION."
                )
            self.count_until_disconnect -= 1

[janiversen]

The most common usage is to work with 1 slave, but the argument hold for your situation as well.

When a request have been retried n times with timeout, the connection is logically considered dead, and thus closed. The app is notified vía an ModbusIOException.

This means the app can use a try/except with a client.connect() to continue.

Not closing, would mean the app cannot reconnect.

Please remember many servers "hang" from time to time, so reconnecting is something the app should master.

[marshfolx]

hmm, so I should use my workaround or set the max count to something like $2^{64} - 1$

[janiversen]

Or make the suggested solution (try/except client.connect()).

As you wrote yourself, it should be left to the app to handle, and it is. What is the practical purpose of continuing sending requests on a dead connection?

[janiversen]

Please remember even if you have multiple servers on the socket, the socket goes to one server that then distributes to the rest. It is that servers responsibility to respond with an exception if a connected server do not respond.

So a missing response means the other end of the socket (the main server) is hanging.

[marshfolx]

Actually, with RTU there is no real "live connection" the way TCP has. RTU over RS-485 is fundamentally different:

• RTU is much closer to the bare metal than TCP.
• It really is a bus: every bit is broadcast to every node on the RS-485 segment, and all devices share the same pair of wires.
• A single RS-485 segment can link 200+ devices / servers.
• When a client "connects", it merely opens its local serial port. No transaction or handshake with any servers on the bus.
• Reconnecting cannot fix anything, unless the fault is an unreliable serial adapter on the client side, which is usually not the case.
• One serial port gives access to the whole bus. If I hit 100 timeouts, there may still be 100 other servers left for me to poll — a timeout from one slave says nothing about the rest of the bus.

By the way, my current software architecture does not allow reconnection during a test process.

[janiversen]

Yes rs485 is very different, but there you can close/open the port as much as you like without the connected slaves knowing about it.

And please no need to tell me about how modbus works, I have a life time experience with developing/standardizing modbus.

I guess you could add a parameter to the serial client, something like "multiple_slaves true/false" and if true not close the port....however I am quite sure that close() can happen in a number of places. An alternative could a no-close parameter.

RTU can also be used on tcp ! so the difference is tcp vs rs-485.

[janiversen]

You have a very special software structure if you cannot put a try/expect around a call !

[janiversen]

But anyhow feel to submit a pull request, which we will review and focus on if it breaks other apps.

[marshfolx]

well, surely it is feasible to add reconnection in them if i really want to. It just looks not tidy to me. I think my project is ok with the workaround.

[janiversen]

#3014 removes closing of serial ports.