PLC 校验字节未知
我试图了解旧机器（PLC）如何在其数据交换中生成校验字节，但我无法弄清楚是做什么以及如何完成的，或者使用的是哪种算法。
我有一份关于机器的非常稀疏的文档，并且我已经尝试了一些算法，例如普通 crc、ccitt crc、xmodem crc 类型...，但没有人给出正确的结果。
该消息的构成如下： M*NNNNNNwwSSdd
其中：
M* - 固定
NNNNNN - N 是数字或空格
ww - w 也是数字或空格
SS - S 是字符或空格
dd - da 数字或空格
一些示例生成下面的字节检查（其中de字节'×'实际上是空格字符''，我使用这个字符只是为了更容易识别空格的数量）
：
- M*614976××××12-> M
- *615138×××××× -> a
b：
- M*615028××××12→ b
- M*615108×××××× -> b
c:
- M*614933×××××× -> c
- M*614956××××12 -> c
d:
- M*614934×××××× -> d
- M*614951××××12 -> d
e:
- M*614942×××××× -> e
- M*615079×××××× -> e
f：
- M*614719××××12→ f
- M*614936×××××× -> fg
：
- M*614718××××12→ g
- M*614937×××××× -> g
h:
- M*614727×××××× -> h
- M*614980××××12 -> h
i:
- M*614734××××12→ i
- M*614939×××××× -> i
- M*×××××××××××× -> i
z：
- M*××××××××SC12→ z
j ：
- M*××××××××××12→ j
y :
- M*××××××××SC×× -> y
还有更多组合，但这些就足够了。
另一个特殊性是，检查字节结果仅存在于定义的范围内 - 从 char 0x60 到 0x7F，仅此而已（当前解决方案有效，因为我在这个范围内循环，直到机器给我一个“ok”）
所以我的问题是，你知道这个校验字节是怎么计算的吗？你能给我指点一些更简单的算法来计算PLC机器中数据的完整性吗？结果字节检查只有一个字符，这一定更简单。
谢谢
I'm trying to understand how a old machine (PLC) generates a check byte in its data exchange, but i can't figure what and how is done or what kind of algorithm is using.
I have a very sparse documentation about the machine and i already try some algorithms like normal crc, ccitt crc, xmodem crc type... and no one is given the right result.
The message is formed like this:
M*NNNNNNwwSSdd
where:
M* - is fixed
NNNNNN - N is a number or a space
ww - w is a number too or a space
SS - S is a char or a space
dd - d a number or a space
Some of the examples generate the following byte check (where de byte '×' is realy the space char ' ', i use this char only to be easier to identify the number of spaces):
a:
- M*614976××××12 -> a
- M*615138×××××× -> a
b:
- M*615028××××12 -> b
- M*615108×××××× -> b
c:
- M*614933×××××× -> c
- M*614956××××12 -> c
d:
- M*614934×××××× -> d
- M*614951××××12 -> d
e:
- M*614942×××××× -> e
- M*615079×××××× -> e
f:
- M*614719××××12 -> f
- M*614936×××××× -> f
g:
- M*614718××××12 -> g
- M*614937×××××× -> g
h:
- M*614727×××××× -> h
- M*614980××××12 -> h
i:
- M*614734××××12 -> i
- M*614939×××××× -> i
- M*×××××××××××× -> i
z:
- M*××××××××SC12 -> z
j:
- M*××××××××××12 -> j
y:
- M*××××××××SC×× -> y
There are more combinations but these ones are enough.
Another particularity is that the check byte result exists only in a defined range - from char 0x60 to 0x7F and no more (the current solution is working because i loop in this range until the machine gives me an ok)
So my question is, do you know how this check byte is calculated? can you point me some simpler algorithms to calculate the integrity of data in PLC machines, it must be simpler that the result byte check is only one char.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，如果我将消息中的所有字符异或在一起，将它们视为 ascii 并用空格替换奇怪的准 x，然后对 0xe 进行异或，我会得到校验和中的字符。至少我建议您构建一个表，显示消息中所有字符的异或以及校验和字符，以十六进制形式写出。考虑到 www.bttautomatyka.com.pl/pdf/HA466357.pdf 中描述的块检查，这样的事情是相当合理的
（我实际上编写了一个 mod-2 方程求解器，并且打算寻找 5 位 CRC，当这个弹出来了！）
It seems to me that if I xor together all the characters in the message, treating them as ascii and replacing your odd quasi-x with space, and then xor in 0xe, I get the character in the checksum. At the very least I suggest that you construct a table showing the xor of all the characters in the message, and the checksum character, written out as hex. Something like this is quite plausible considering the block check described in www.bttautomatyka.com.pl/pdf/HA466357.pdf
(I had actually written a mod-2 equation solver and was going to look for a 5-bit CRC, when this popped out!)