Cannot participate as slave on a multi-drop bus if there are other slaves

[ksjoberg]

Versions

• Python: 3.7
• OS: Current Raspberry OS
• Pymodbus: 2.5.2
• Modbus Hardware (if used): Exar CC-USB-RS485-150U / Exar 21B1411

Pymodbus Specific

• Server: rtu - sync + async
• Client: rtu - sync + async

Description

In serial/RTU mode, PyModbus participates on a Modbus bus using PySerial. Unfortunately, PySerial's read behaves differently to recv on sockets, as the pySerial timeout defines how long time it has to fill the 1024 bytes buffer of PyModbus before it has to return whatever it managed to get instead of filling the buffer with the payload of a TCP packet. This results in delayed processing as it could take up to a second for the ModbusSerialServer to start processing the message(s). The delay causes the requestor to retry its request, further filling the buffer of identical requests.

PyModbus in general seem to be unable to handle participation on multi-drop bus as Modbus over RS485 is, because a server can only parse requests. It gets confused seeing Modbus responses it has not generated itself on the wire it serves on as a server.

It seems a server can only, and is only expected to, have a ServerDecoder. Such a decoder can only parse Modbus Requests. When it fails, such as when a Response appears on the line, it will flush the buffer and lose data, including valid Requests still pending to be parsed. This flush of the input buffer again causes the requestor to retry its request and may/will trigger a failure-to-respond status of the PyModbus-implemented server.

While PyModbus attempts to do add framing of outgoing data by pausing between frames for 3.5 char times, it does not attempt to detect pauses between frames on incoming data. This makes the serial stream be an unframed series of bytes. As consequence, to recover framing information it must properly be able to parse both requests and responses (of all types present on the bus) to not come out of sync. This it does not do (yet?), either.

[janiversen]

Can you please check with version 3.0.2, I believe this is no longer an issue.

[peufeu2]

I've looked into it and I don't think it's possible to solve this at the python level.

• 1.5 char modbus timeout is about 1.5ms at 9600bps

pyserial's inter_byte_timeout only has a granularity of 0.1s, so it won't work.

The usual USB-RS485 or USB-serial adapters only run "full speed" USB, ie 12 Mbps and they transmit one frame per millisecond, so even if the OS told userland code at what microsecond timestamp a serial byte arrived on USB, the OS itself it would not know the exact arrival time of the bytes to the USB dongle with better than millisecond precision.

With hardware UARTs like the ones embedded in the Pi's, then the OS has at least a chance to implement such a short timeout, but will it? That's another question. I would bet on "nope" because heavyweight OSes like linux don't guarantee such low latencies anyway. Besides these chips' UARTs usually have FIFOs and DMA to avoid triggering too many interrupts, and by the time the bytes are in the FIFO, arrival time information is lost. So the UART hardware itself would have to have an inter_byte timeout feature. That's a thing in some microcontrollers, precisely to implement modbus.

Besides from the python side there can be latency between byte arrival time and serial.read() return due to the computer multitasking, other async coroutines running, etc. So measuring arrival time from the python side should only result in more dropped packets when latency is higher.

The simplest solution looks to be a hardware fix, with a microcontroller acting as a serial-to-modbus translator. On a micro running no other task there will be no latency issues to implement an inter-byte timeout. The micro would have to frame data transmitted to pymodbus to indicate packets, fortunately modbus is pretty slow and USB-serial links can run at hundreds of kbps so framing overhead shouldn't be an issue.

https://stackoverflow.com/questions/58898980/how-to-set-inter-byte-delay-timeout-to-milliseconds
pyserial/pyserial#88

[janiversen]

The problem here is not timing, but that he server receives responses from other slaves. When receiving a message it must be validated that it is destined for the server and otherwise discharged.

[peufeu2]

That's easy: if the modbus frame's address header doesn't match the server's address, then the whole frame can be dropped. Problem is, in order to do that, the end of the frame has to be found, and the only way to do that is to detect inter-byte delay which is not possible for reasons explained above.

Without the extra meaning from the inter-byte delay, python will have no idea where the frames begin or end, unless we're the only master, or we're the only slave...

Parsing the packets wouldn't help: if another device crashes and stops its transmission mid-frame, the bus becomes available immediately after the timeout, so the master can transmit immediately if it wants, for example it could retry the transaction. And pyserial would receive one truncated packet followed by the new transmission, with no way to distinguish the two.

[janiversen]

There are quite a number of options, which will work….we do not need the inter har,

• we can store the request and from that calculate the response.
• the slave id is at the beginning of the response so we do need the whole frame

[dlmoffett]

Hey is there any update or workaroud to this?

I have just encountered and learned about this issue on

[[package]]
name = "pymodbus"
version = "2.5.3"

In the meantime I am in the process of updating to

[[package]]
name = "pymodbus"
version = "3.1.3"

in the hopes that it has been addressed; however seeing as this issue is still opened and marked for Version 3.3 I'm not optimistic.

I'm opened to any off-the-shelf hardware workarounds if anyone knows of such a thing? Something I can stick in front of my serial port to properly frame and filter responses from other server/slaves would be acceptable.