Most complete Modbus library for Arduino. A library that allows your Arduino board to communicate via Modbus protocol, acting as a master, slave or both. Supports network transport (Modbus TCP) and Serial line/RS-485 (Modbus RTU). Supports Modbus TCP Security for ESP8266/ESP32.
Other
534
stars
190
forks
source link
- Added flag to receive packets with invalid CRC as well #301
Hi,
I'm coping right now with a brand new solar inverter that pretends to talk Modbus on RS485. However, if I invoke function 0x3 to read registers and an invalid range is specified (the addressing seems to be split in many different sub-ranges), instead of answering:
[0x01] [0x83] [0x02] [CRC] [CRC]
(where 0x1 is obviously the node Id), it always wrongly respond with:
[0x01] [0x90] [0x02] [0x00] [0x00]
with two errors: respond to the function 0x10 + error flag, rather than the 0x3, and it fails to present a valid CRC, the two bytes are always zero.
I'm not sure if this is a firmware issue that will be corrected in the future, or if it is part of a some non-standard code.
However, I was interested in receiving such strange errors and process them correctly. Currently, the library rejects the packet due to CRC error.
The idea is to be able to receive malformed packet (I can see there is already a partial support there). However, for compatibility, I suggest to add a new argument to the onRaw, in order to specify the willing to receive also CRC-failed packets.
In addition, I added a validFrame boolean flag in the frame_arg_t argument, that is not set in case of CRC errors or in the previously covered cases of wrong node id.
I separated the onRaw of the base class, used by the TCP implementation, since CRC is only on the RTU side.
Please let me know what you think about it.
Thanks! L.
Hi, I'm coping right now with a brand new solar inverter that pretends to talk Modbus on RS485. However, if I invoke function 0x3 to read registers and an invalid range is specified (the addressing seems to be split in many different sub-ranges), instead of answering:
(where 0x1 is obviously the node Id), it always wrongly respond with:
with two errors: respond to the function 0x10 + error flag, rather than the 0x3, and it fails to present a valid CRC, the two bytes are always zero. I'm not sure if this is a firmware issue that will be corrected in the future, or if it is part of a some non-standard code.
However, I was interested in receiving such strange errors and process them correctly. Currently, the library rejects the packet due to CRC error.
The idea is to be able to receive malformed packet (I can see there is already a partial support there). However, for compatibility, I suggest to add a new argument to the
onRaw, in order to specify the willing to receive also CRC-failed packets.In addition, I added a
validFrameboolean flag in theframe_arg_targument, that is not set in case of CRC errors or in the previously covered cases of wrong node id.I separated the
onRawof the base class, used by the TCP implementation, since CRC is only on the RTU side.Please let me know what you think about it. Thanks! L.