search

MangoAutomation / modbus4j

A high-performance and ease-of-use implementation of the Modbus protocol written in Java. Supports ASCII, RTU, TCP, and UDP transports as slave or master, automatic request partitioning and response data type parsing.
GNU General Public License v3.0
897 stars 370 forks source link

I think the message decoding in MessageControl#data is fault-intolerance or a bug. #40

Open duzean opened 3 years ago

duzean commented 3 years ago

So why is it so designed.

terrypacker commented 3 years ago

@duzean we will need a lot more information to help you out. Please provide an example of your problem so we can reproduce it and test.

duzean commented 3 years ago

@terrypacker Sorry for my sentence.I implement my InputStreamEPollWrapper for RtuMaster, and the actual slave sometimes return some bad bytes not suit modbus protocol. I assume the message decoder is fault-tolerance in this situation.But when a bad response is appear, the MessageControl#data is never work right again.

duzean commented 3 years ago

But when I filter the bad bytes that not suit for modbus protocol, everything is ok. So I assume it is a bug.

duzean commented 3 years ago

@terrypacker Because when a bad response appear, it is go wrong, even though every continue response is right. Do you need some actual response bytes?

terrypacker commented 3 years ago

@duzean it would help to see the message that is causing the failure. That way I can write a test to replicate it exactly. Thanks.

duzean commented 3 years ago

Here is the request and response, hope that helps. send: 04040014000CB05E recv: 040418000403E7004D004F000000000000FA2A000003441CA205152AAB send: 0404004F0006418A recv: 04040C00160022002F00BC00C8004BD48D send: 04040014000CB05E recv: 04 // after this point every read action throw ModbusTransportException but the slave give right response send: 04040014000CB05E recv: 040418000403E700510053000000000000FA2A000003441CA2051535FF send: 04040014000CB05E recv: 040418000403E700510052000000000000FA2B000003441CA10514583F send: 04040014000CB05E recv: 040418000403E700500052000000000000FA2B000003441CA1051465C3

duzean commented 3 years ago

@terrypacker I think when checkCRC failure or get a wrong functionCode, it is necessary reset the mark and skip one byte for another parse. And before send request, clear the dataBuffer.