How to Catch ModbusIOException

[nicholas-a-guerra]

I'm just curious on how to handle one exception I see popup. My setup has a TCP converter connected to a serial device. Sometimes the serial device will be down but I'll still be able to connect to the converter. This seems to propagate a few exceptions. One is the ModbusException which happens when I try to do things like read_holding_registers. That part works great and as expected. But is also seems to propagate a ModbusIOException every so often but not every call.

It looks like this:

Fatal error: protocol.data_received() call failed.
protocol: <pymodbus.client.tcp.AsyncModbusTcpClient object at 0x100cc24d0>
transport: <_SelectorSocketTransport fd=6 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/asyncio/selector_events.py", line 1009, in _read_ready__data_received
    self._protocol.data_received(data)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 335, in data_received
    cut = self.cb_handle_data(self.recv_buffer)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/client/base.py", line 210, in cb_base_handle_data
    self.framer.processIncomingPacket(data, self._handle_response, slave=0)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/framer/socket_framer.py", line 173, in processIncomingPacket
    self._process(callback, tid)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/framer/socket_framer.py", line 180, in _process
    raise ModbusIOException("Unable to decode request")
pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request

The trouble I'm having is that I don't know where this is being propagated. Generically catching all exceptions on read_holding_registers doesn't catch this. Any idea where I can capture this to control the output?

Thanks!

[janiversen]

That depends a lot on whether you are using async or sync, an the version you use.

[nicholas-a-guerra]

Sorry about that, missed those import details! I'm using async and version 3.3.2. But I can update right now. Just realized I was on an older version. Would this behavior change with the update to 3.6.6 on pip?

[nicholas-a-guerra]

Looks like on 3.6.6 it now changes to:

General exception: unpack requires a buffer of 2 bytes
Fatal error: protocol.data_received() call failed.
protocol: <pymodbus.client.tcp.AsyncModbusTcpClient object at 0x101269d10>
transport: <_SelectorSocketTransport fd=6 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/asyncio/selector_events.py", line 1009, in _read_ready__data_received
    self._protocol.data_received(data)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 303, in data_received
    self.datagram_received(data, None)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 337, in datagram_received
    cut = self.callback_data(self.recv_buffer, addr=addr)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/client/base.py", line 201, in callback_data
    self.framer.processIncomingPacket(data, self._handle_response, slave=0)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 139, in processIncomingPacket
    self.frameProcessIncomingPacket(single, callback, slave, **kwargs)
  File "/Users/nicholasguerra/Local Dev/Connection_Manager/venv/lib/python3.11/site-packages/pymodbus/framer/socket_framer.py", line 106, in frameProcessIncomingPacket
    raise ModbusIOException("Unable to decode request")
pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request

[janiversen]

You need a try/except ModbusIOException, around your read call to capture the exception, please see our examples.

[janiversen]

Just copy the example like f.x simple async client. that does it correctly

And furthermore it is being tested.

ModbusIOException is catchable, and should be caught.

[janiversen]

https://pymodbus.readthedocs.io/en/latest/source/examples.html

[nicholas-a-guerra]

This is what I tested. And we still get the results above. I believe if this exception is being raised in a task created within read_holding_registers or connect or something then this won’t be propagated up the way we’re hoping.

[janiversen]

Let me try to test manually our examples.

[nicholas-a-guerra]

Thank you

[janiversen]

The example works !!

I modified the examples:

diff --git a/examples/simple_async_client.py b/examples/simple_async_client.py
index 91f9665a..b186f8ad 100755
--- a/examples/simple_async_client.py
+++ b/examples/simple_async_client.py
@@ -84,11 +84,12 @@ async def run_async_simple_client(comm, host, port, framer=Framer.SOCKET):
     assert client.connected
 
     print("get and verify data")
+    await asyncio.sleep(10)
     except ModbusException as exc:
-        print(f"Received ModbusException({exc}) from library")
+        print(f"XXXJAN Received ModbusException({exc}) from library")
         client.close()
´´´

And the log shows:

2024-03-16 23:42:23,857 DEBUG logging:103 Connecting to 127.0.0.1:5020.
2024-03-16 23:42:23,857 DEBUG logging:103 Connecting comm
2024-03-16 23:42:23,858 DEBUG logging:103 Connected to comm
2024-03-16 23:42:27,776 DEBUG logging:103 -> transport: received eof
2024-03-16 23:42:27,776 DEBUG logging:103 Connection lost comm due to None
2024-03-16 23:42:27,777 DEBUG logging:103 callback_disconnected called: None
2024-03-16 23:42:27,777 DEBUG logging:103 Wait comm 100.0 ms before reconnecting.
...REPEAT internally (reconnect).
2024-03-16 23:42:33,800 DEBUG logging:103 Wait comm 200.0 ms before reconnecting.
get client
connect to server
get and verify data
XXXJAN Received ModbusException(Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 127.0.0.1:5020]) from library

So again, please look at the example it works.


As you can see the exception is catches (XXXJAN shows it clearly).

[nicholas-a-guerra]

Looking through the code it looks like I was able to track down the exception back to a callback method. This would suggest to me if it is within a callback method then catching the read_holding_registers wouldn't work (only for this exception). It seems a callback originating from asyncio.BaseProtocol. I have successfully caught ModbusException for other exception types with read_holding_registers in a try block. That works perfectly as intended. It's only this Unable to decode request exception that isn't catching. Here's the tracking I did of the exception. File name and line numbers are included.

pymodbus/pymodbus/transport/transport.py
134 | class ModbusProtocol(asyncio.BaseProtocol):
305 | def datagram_received(self, data: bytes, addr: tuple | None) -> None:
337 | cut = self.callback_data(self.recv_buffer, addr=addr)

pymodbus/pymodbus/client/base.py
20 | class ModbusBaseClient(ModbusClientMixin[Awaitable[ModbusResponse]], ModbusProtocol):
196 | def callback_data(self, data: bytes, addr: tuple | None = None) -> int:
201 | self.framer.processIncomingPacket(data, self._handle_response, slave=0)

pymodbus/pymodbus/framer/base.py
22 | class ModbusFramer:
115 | def processIncomingPacket(self, data, callback, slave, **kwargs):
139 | self.frameProcessIncomingPacket(single, callback, slave, **kwargs)

pymodbus/pymodbus/framer/socket_framer.py
18 | class ModbusSocketFramer(ModbusFramer):
63 | def frameProcessIncomingPacket(self, single, callback, slave, tid=None, **kwargs):
106 | raise ModbusIOException("Unable to decode request")

[janiversen]

Now I see what you try to do, that is not possible.

That is an internal exception which is caught internally, and causing the reconnect task to run. At the app level you get an exception when reconnect do not work.

The callback you found is the callback that delivers data, and socket_framer is where the data is being decoded (ready to be delivered back to the app. Without having checked I am pretty sure the async_execute catches this, but will have a look.

Now what is the reason you want to catch that specific exception ? the idea is to handle it automatically unless you block reconnect.

[nicholas-a-guerra]

I see, this seems undesirable when attempting to control output. Maybe this exception could be logged instead of propagated through raises? This way it can be avoided through logging levels? Otherwise I guess the only control as a user is to capture all stderr and parse that out specifically?

[janiversen]

Well we need the exception in order to bypass an unknown call stack.

Logger and stack traces writes to stderr, so you can catch it there.

[janiversen]

Independent of that, pull requests are welcome if you want changes.

[nicholas-a-guerra]

Understood, well I do have a better understanding now at least. Thanks for the assistance and great library!

[janiversen]

Just tested again, the client call is:

    try:
        resp = await client.read_holding_registers(address=124, count=4, slave=0)
    except ModbusException as exc:
        txt = f"ERROR: exception in pymodbus {exc}"
        Log.error(txt)
        return
    if resp.isError():
        txt = "ERROR: pymodbus returned an error!"
        Log.error(txt)

and the response I get:

2024-03-17 13:48:23,025 ERROR logging:115 ERROR: exception in pymodbus Modbus Error: [Input/Output] Unable to decode request

so the exception can be catched (we actually reraise the original exception).

[nicholas-a-guerra]

Right but it seems to also still print to stderr too as a separate uncaptured exception within the callback. My main point was to be able to control all of the output. Essentially this is going to be production code and I’d like to be more customized with my output during these events so I can track precisely what is happening. (Example: “Inverter 4 is connected to tcp converter but modbus response is unable to decode”) With the reraised exception, I suppose I can still partly do this but the output is still going to be flooded with the uncaptured exceptions in the callback. So this is the not ideal part but I agree with you this is maybe less than straight forward to come up with a perfect solution.

[janiversen]

Just fyi I have no stray exceptions in the last tests I made, nor any stderr output. The exception goes directly to the except clause.

I am testing on dev, but I do not think there are a lot of differences in this part.

[janiversen]

The output on the console is what I copied (from the except clause). I cannot reproduce your uncaught exception.

[nicholas-a-guerra]

Interesting, okay tomorrow I’ll test again and share the test code (I’ll use only the example code) and my output. I’m surprised based on the discovery of the callback that you’d even be able to re raise it. I thought it would occur within a task, which is likely not awaited specifically by the read_holding_registers. Regardless, if it’s my mistake that would be great. I’ll report back tomorrow. Thanks!

[nicholas-a-guerra]

Apologies for the delay on this. The hardware configuration has changed such that I currently won't get the same error. However, I'm comfortable with either possibility now. Either somehow I've missed the catch or the exception is in a asyncio task that can't be captured. With the information provided though I generally understand what the possibilities are and what I'll likely need to do in either situation. I appreciate the feedback!