ModbusTcpClient always connected and recconect when droped.

[bambosd]

Hello everyone,
we have a scenario when a modbus tcp client need to stay always connected to another modbus tcp server device, to pass modbus writes commands spontaneously based on events coming from another system and at the same time reading in loop some holding registers from the same device. utilizing 2 separate clients will result in double connection to the server that is not considered good practice.

I noticed that the ModbusTcpClient object, is not able to make a reconnection, unless the client.close() is executed.
When i tried to use try / except block and add client.connect() in case of except, is not able to re-establish the connection, and the parameters client.connect() and client.connected() are reporting True. (check that with print).

Is this the normal expected behavior ? Even if i want to handle reconnection, I'm not able to because the client.close() is needed.
Can this scenario be executed with the sync version of the client ? Is this a use case for the async client ??

Any comments appreciated. test code below.

Versions

• Python: 3.13.9
• OS: Windows 10
• Pymodbus: 3.15.0
• Modbus Hardware (if used): Nodered Modbus TCP Server

Code and Logs

import time
import logging
from pymodbus.client import ModbusTcpClient

logging.basicConfig(level=logging.INFO)

client = ModbusTcpClient("192.168.6.69", port=1502)

while True:
    try:
        # 2. Open the connection
        if client.connect():
            print("Successfully connected to SERVER")

            result = client.read_holding_registers(address=0, count=5, device_id=1)
    
            if result.isError():
                print(f"Modbus Error: {result}")
            else:
                # Access the data via the .registers list
                print("Successfully read registers!")
                print(f"Raw register values: {result.registers}")
            #client.close()
    except:
            print("Failed to connect to SERVER")
            client.connect()
            print('client connected property : ' , client.connected)
            print('client connect property : ' , client.connect())
    

    time.sleep(1)

[janiversen]

I am not really understanding your description.

A client is connected until .close() is called or the device terminates the connection, in the later case the client tries to reconnect automatically.

once a client is disconnected, there are no api calls to reconnect. The reason being that a lot of the connect configuration happens in init. when .connected is false you should be able to simply call .connect().

So checking .connected before making write operations should solve your problem.

a couple of note .connected is a property not a method !

Of course you cannot connect and already connected object, that would be strange to allow that.

If you want ,connect() to work differently feel free to submit a pull request.

[bambosd]

Hello Sir, client.connect() is not working correctly if client.close() is comment out, as per my example above.
So having client.connect() in except, can't re-establish the connection, even this was what i expected.
If client.close() is in place, and executing in every loop, a reconnection is possible and successful.

Is there any way to achieve persistent connection with reconnection with sync client ? or you suggest the async client ?

[janiversen]

No of course client.connect() do not work if a connection is active.

You need to check client.connected if that is true client.close() must be called before client.connect().

One simple solution is to call client,close() in the except: before calling client,comnect().

[janiversen]

your except is catching everything, so you do not know is it originates from the connect or the read, and thus you do not know the state of the connection.

an exception e.g. read do NOT close the connection, allowing you to continue with a new requests.

[IDavinciCode]

The sync client works fine for this (one TCP connection, cyclic reads plus event driven writes). Putting together what janiversen said, plus two things that are easy to miss:

1. if your writes come from another thread (callbacks from the other system) you need a lock, the sync client is not meant to be used from two threads at once;
2. when the server drops the socket, the next request on 3.15 raises a plain ConnectionResetError (an OSError) from the socket send, not a pymodbus ConnectionException, so catch both.

Something like this:

import threading
import time
from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ConnectionException, ModbusException

client = ModbusTcpClient("192.168.6.69", port=1502, timeout=2)
lock = threading.Lock()

def ensure_connected():
    # connect() on an object that still thinks it is connected does nothing,
    # so close first, then connect
    if not client.connected:
        client.close()
        return client.connect()
    return True

def poll_loop():
    while True:
        with lock:
            try:
                if ensure_connected():
                    rr = client.read_holding_registers(address=0, count=5, device_id=1)
                    if not rr.isError():
                        print(rr.registers)
            except (ConnectionException, OSError):
                client.close()      # link is gone, next pass reconnects
            except ModbusException as exc:
                print("modbus error, connection kept:", exc)
        time.sleep(1)

def write_on_event(address, value):
    with lock:
        try:
            if ensure_connected():
                client.write_register(address, value, device_id=1)
        except (ConnectionException, OSError):
            client.close()

I tested it on 3.15.0 against a local pymodbus server: read and a write from a second thread, then killed the server (first poll gets the reset and closes, the next ones fail to connect), restarted it, and the following poll reads again without restarting the client.

Two things from your original code:

• the bare except catches everything, so after an error you can't tell if the link is gone or one request failed. A ModbusException like a timeout or an exception response does not drop the connection; a connection error does, and that's the case where you close and reconnect.
• connected is a property: client.connected, not client.connected().

If the rest of your program is already asyncio you can do the same with AsyncModbusTcpClient and one task for polling, then you don't need the lock.

[janiversen]

Calling client.connect() on an open SERIAL connection, will pr design just return true...there are no reconnect.