[a.pythe]

@Mikhail, zamechatelno! 🙂 Thank you.

[a.pythe]

@Mikhail, by the way, maybe sometime you’ll take a look at a much smaller bug mentioned in this discussion.

Testing example byte set: 10 06 02 02 00 45 EB 01
It has intentionally corrupted CRC value to verify the Parser’s response.
Actual Parser’s response: “Data package CRC error. Actual CRC is EB 00. Expected CRC is EB 00″
Correct message shoul be: “Data package CRC error. Actual CRC is EB 01. Expected CRC is EB 00″

It seems the Parser always prints most significant byte zeroed in such a message.

Thansk in advance.

[a.pythe]

Yyyyess-s-s-s!!

@Mikhail, thank you greatly!

[a.pythe]

0xBADD is displayed by the parser in the same order as transferred.

@Mikhail, I know!

We’ve told this three or four times in the above discussion – me and @manjey73 🙂

And that’s what is wrong with it.

Because according to Modbus specification the CRC is transferred in the reverse order, unlike all other 16-bit values in the package.

I’d be obliged if your check will encompass Modbus Serial Line Protocol and Implementation Guide V1.02, namely part 2.5.1.2 CRC Checking.

• This reply was modified 3 weeks, 5 days ago by a.pythe.
• This reply was modified 3 weeks, 5 days ago by a.pythe.

[a.pythe]

@Mikhail, shure.

Testing example byte set, 6 (six) bytes length: 01 02 03 04 05 06

Whatever the set is, it’s CRC-16/MODBUS value is DDBA(hex) 56762(dec)

So, according to the Modbus specification the set with CRC bytes added is 01 02 03 04 05 06 BA DD

When fed to the Rapid SCADA Modbus Parser this set is parsed as a good data package, but it’s CRC shown at the bottom of the page is presented in reverse byte order as BADD(hex) 47837(dec) integer.

Make shure 47837 is not equal to 56762.

Thank you for your attention to this matter! 🙂

[a.pythe]

Exactly! Thank you for your input.

And three of four first CRC functions found in the net will treat the CRC of this package as F26A, not 6AF2.

The fourth function found just mimics the ancient style of the algorithm, calculating Hi and Lo bytes apart. Which honors old 8-bit processors like i8051, I believe. Still even the fourth function names high and low bytes of the CRC correctly.

By the way, the Parser treats packages with CRC errors a bit amusingly. For example, feed it with 10 06 02 02 00 45 EB 01 package (depicts damaged CRC), and it will reply: Data package CRC error. Actual CRC is EB 00. Expected CRC is EB 00.

[a.pythe]

the calculation is correct, but the displayed value is incorrect

Just in point! 🙂 I never managed so succinctly.

[a.pythe]

Hi, Mikhail! 🙂

In turn can you kindly explain me, what is “the practice” which overtakes general programming standards and official Modbus documentation? Why on earth should you follow the practice and where in the world the practice exists? I’ve only found sources which support my view
https://github.com/LacobusVentura/MODBUS-CRC16
https://www.modbustools.com/modbus.html

Folks seem discuss this topic too, still I never saw your point got favored
https://github.com/stephane/libmodbus/issues/397
https://control.com/forums/threads/byte-order-of-modbus-crc.11616

It seems not an issue if you are a common user, still being a programmer, the misconception (lacking one short line of code) leads directly to a glaring fault. Let us look at you points.

[a.pythe]

Thank you very much! Indeed, the Parser is a very useful and handsome tool particularly for learning and teaching purposes. The issue is just a pesky thing, still it cost me a big discussion with my colleagues 🙂

[a.pythe]

Thanks for your reply, but I am misunderstood, sorry. I’ve no doubts on the order of bytes. The question is how to represent these bytes as a whole 16-bit integer.

The authorized Implementation Guide proclaims the sequence as a *little-endian order*. You’ve just approved it in the above. Instead, the Parser represents it as *big-endian byte sequence*, that is, the FIRST byte of the two, which you’ve just said is LOW ORDER byte, it places to the HIGH ORDER byte of the CRC.

Imagine, you have a Modbus message XX XX XX XX XX XX AB CD, ending with 0xAB (low order byte), 0xCD (high order byte). The correct 16-bit integer CRC should then read as 0xCDAB. While the Parser would present it as 0xABCD, which is digital abuse and harassment 🙂

For example: 10 06 02 02 00 03 6A F2 (see the Parser web-page).

Here low-order byte is 0x6a, high-order byte is 0xf2, which makes it 0xf26a (hex) or 62058 (dec) integer.

Still the Parser says it be 0x6AF2 (27378 dec).

Is it wrong, no?

• This reply was modified 1 month, 2 weeks ago by a.pythe.

[Author]

Posts