Broadcast responses handling in Sync RTU #383
Comments
|
Interesting bug report, are you running pymodbus rtu server with one unit on the same port in two numbers or just one pymodbus server with 2 units ? Could you please share the logs of the second server receiving the response ? Also the code for your server as well. |
|
I have three processes. One client and two servers (one with units 0x01 and 0x02 and the other with units 0x03 and 0x04). Basically all messages are broadcated to all processes including responses. However as servers have a Minimal working exampleCode for servers (replace unit IDs with 3 and 4 for other server and /dev/ttyUSB2): import logging
from pymodbus.server.sync import ModbusSerialServer
from pymodbus.datastore import ModbusSequentialDataBlock
from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext
from pymodbus.transaction import ModbusRtuFramer
if __name__ == "__main__":
logging.basicConfig(level=logging.DEBUG)
# Initialise slave and its components
context = ModbusServerContext(slaves={
unitId: ModbusSlaveContext(
di=ModbusSequentialDataBlock(0x00, [False]*0x10),
co=ModbusSequentialDataBlock(0x00, [False]*0x10),
hr=ModbusSequentialDataBlock(0x00, [0]*0x10),
ir=ModbusSequentialDataBlock(0x00, [0]*0x10),
zero_mode=True
) for unitId in [0x01, 0x02]
}, single=False)
slave = ModbusSerialServer(
context,
ModbusRtuFramer,
ignore_missing_slaves=True,
port='/dev/ttyUSB1',
baudrate=115200,
timeout=2,
)
# Initialize channel
slave.serve_forever()Code for client: import logging
from pymodbus.client.sync import ModbusSerialClient
if __name__ == "__main__":
logging.basicConfig(level=logging.DEBUG)
client = ModbusSerialClient(method='rtu', port='/dev/ttyUSB0', timeout=2, baudrate=115200)
client.connect()
client.read_coils(0x01, 1, unit=0x01).bits[0]
client.read_coils(0x02, 1, unit=0x02).bits[0]
client.read_coils(0x03, 1, unit=0x03).bits[0]
client.read_coils(0x04, 1, unit=0x04).bits[0]
client.close()LogsLog for client:
Logs for server 1:
Logs for server 2:
With pymodbus 2.2.0.rc2 (6960d9c)Logs for server 1:
Logs for server 2:
Logs for client:
Fix similar to #376 def processIncomingPacket(self, data, callback, unit, **kwargs):
if not isinstance(unit, (list, tuple)):
unit = [unit]
self.addToFrame(data)
single = kwargs.get("single", False)
if self.isFrameReady():
if self.checkFrame():
if self._validate_unit_id(unit, single):
self._process(callback)
else:
_logger.debug("Not a valid unit id - {}, "
"ignoring!!".format(self._header['uid']))
self.resetFrame()
else:
_logger.debug("Invalid CRC")
self.resetFrame()
else:
_logger.debug("Frame - [{}] not ready".format(data))Logs for client:
Logs for server 1:
Logs for server2:
As I'm calling |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
This issue was closed because it has been stalled for 5 days with no activity. |
Versions
Pymodbus Specific
Description
What were you trying, what has happened, what went wrong, and what did you expect?
One client speaks with two servers. Servers have different unit ids (e.g., server 1 has unit id 1 and server 2 has unit id 2). When client requests on server 1, server 2 also receives request and drops it due to code in ModbusRtuFramer.processIncommingPacket:218 (which is good).
However, server 2 also receives answer from server 1 which is badly parsed because decoder is a
ServerDecoderwhich doesn't know how to handle responses. Thus CRC verification fails and most likely end-up with the same issues raised in #376 and #356.According to PR, this should be fixed in release 2.2.0.
Can you confirm my analysis of the problem and is 2.2.0 scheduled?
I was also wondering if it wouldn't be easier to just validate unit id before even computing CRC?
Also, maybe I am doing things wrong on having
Thanks a lot,
Best
The text was updated successfully, but these errors were encountered: