- This topic has 24 replies, 3 voices, and was last updated 3 weeks, 4 days ago by
.
-
Posts
-
@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! 🙂
0xBADD is displayed by the parser in the same order as transferred.
https://ibb.co/tpS0C1Zm
https://ibb.co/v7fyV3SI’ll check the details and come back.
Thank you for noticing.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.
Yyyyess-s-s-s!!
@Mikhail, thank you greatly!@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.
@Mikhail, zamechatelno! 🙂 Thank you.
- You must be logged in to reply to this topic.