- This topic has 15 replies, 3 voices, and was last updated 14 hours, 32 minutes ago by
.
-
Posts
-
When playing the online Rapid SCADA Modbus Parser, I’ve noticed queer CRC presentation at the bottom of the player.
As of Modbus Serial Line Protocol and Implementation Guide V1.02:
“2.5.1.2 CRC Checking …
When the CRC is appended to the message, the low-order byte is appended first, followed by the high-order byte. A detailed example of CRC generation is contained in Appendix B.”In Appendix B there is an example of proper relations between the byte sequence and integer presentation of a CRC tail of a Modbus message. Unlike register address, which is written to the message as a big-endian integer, CRC is written as a little-endian integer, so byte sequence must appear there “in reverse”.
Instead, the online Rapid SCADA Modbus Parser treats CRC bytes as big-endians which seam inexact.
In Modbus, the lowest CRC byte always goes first, then the highest.
A feature of the CRC calculation in the Modbus protocol is that if we send a packet along with the CRC to the calculation, we should get 0Thanks 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?
Yes, it’s wrong. I understand what you’re talking about. Displaying the CRC value in the parser.
I very rarely use this parser, let’s hope @Mikhail will correct this moment.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 🙂
Instead, the online Rapid SCADA Modbus Parser treats CRC bytes as big-endians which seam inexact.
According to the practice, the Modbus Parser calculates correctly 🙂
If you find a difference in CRC comparing to the real Modbus device, let us know.the calculation is correct, but the displayed value is incorrect, since the CRC in Modbus is always inserted the lowest byte ahead.
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.htmlFolks 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.11616It 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.
the calculation is correct, but the displayed value is incorrect
Just in point! 🙂 I never managed so succinctly.
Enter there 10 06 02 02 00 03
And then enter 10 06 02 02 00 03 F2 6A if the byte order in the CRC corresponded to the display of the VALUE in the parser
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.
Well, @Mikhail can easily see his mistake. It is enough to look at the result of the CRC calculation in the Modbus driver before it is split into bytes for the packet 🙂
no matter how many times I used the parser, I always focused on the fact that CRC = OK, and I didn’t even pay attention to the value itself. 🙂
Hi,
If you find a bug, please provide the structured info:
– Testing example
– Expected result of the Modbus parser
– Actual result provided by the Modbus parserAccording to the rules of the Modbus package, the lowest byte is indicated first, and the highest byte is indicated last. But that doesn’t mean that the meaning has suddenly changed, does it?
- You must be logged in to reply to this topic.