gpt4 book ai didi

c++ - 二进制 PLC 通信的校验和

转载 作者:搜寻专家 更新时间:2023-10-31 01:10:30 27 4
gpt4 key购买 nike

我一直在绞尽脑汁计算校验和,以便使用二进制命令与 Unitronics PLC 进行通信。他们提供了源代码,但它是在仅限 Windows 的 C# 实现中,除了基本语法外,这对我帮助不大。

Specification PDF (校验和计算接近尾声)

C# driver source (Utils.cs中的校验和计算)

预期结果

下面是字节索引、消息描述和有效的示例。

#  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | 24 25 26 27 28 29 | 30 31 32
# sx--------------- id FE 01 00 00 00 cn 00 specific--------- lengt CHKSM | numbr ot FF addr- | CHKSM ex
# 2F 5F 4F 50 4C 43 00 FE 01 00 00 00 4D 00 00 00 00 00 01 00 06 00 F1 FC | 01 00 01 FF 01 00 | FE FE 5C

规范要求分别计算 22 字节消息头和 6+ 字节详细信息的累加值,得到对 65536 求和的值,然后返回该值的二进制补码。

尝试#1

我的理解是 Python 中的波浪号 (~) 运算符直接源自 C/C++。在编写了创建消息的 Python 一天后,我想到了这个(精简版):

#!/usr/bin/env python

def Checksum( s ):
x = ( int( s, 16 ) ) % 0x10000
x = ( ~x ) + 1
return hex( x ).split( 'x' )[1].zfill( 4 )

Details = ''
Footer = ''
Header = ''
Message = ''

Details += '0x010001FF0100'

Header += '0x2F5F4F504C4300FE010000004D000000000001000600'
Header += Checksum( Header )

Footer += Checksum( Details )
Footer += '5C'

Message += Header.split( 'x' )[1].zfill( 4 )
Message += Details.split( 'x' )[1].zfill( 4 )
Message += Footer

print Message

消息:2F5F4F504C4300FE010000004D000000000001000600600L010001FF010001005C

我在那里看到一个 L,这与昨天的结果不同,昨天的结果并没有更接近。如果您想要基于消息其余部分的快速公式结果:Checksum(Header) 应返回 F1FC,而 Checksum(Details) 应返回 FEFE

它返回的值与规范的示例相去甚远。我相信问题可能出在一两件事上:Checksum 方法没有正确计算十六进制字符串的总和,或者 Python ~ 运算符不等同于 C++ ~ 运营商。

尝试 #2

一个 friend 给了我他对计算应该是什么的 C++ 解释,我只是无法理解这段代码,我的 C++ 知识很少。

short PlcBinarySpec::CalcHeaderChecksum( std::vector<byte>  _header ) {
short bytesum = 0;
for ( std::vector<byte>::iterator it = _header.begin(); it != _header.end(); ++it ) {
bytesum = bytesum + ( *it );
}
return ( ~( bytesum % 0x10000 ) ) + 1;
}

最佳答案

我不完全确定正确的代码应该是什么……但是如果 Checksum(Header) 的目的是返回 f705,而它返回的是 08fb,那么问题就来了:

x = ( ~( x % 0x10000 ) ) + 1

简短的版本是你想要这个:

x = (( ~( x % 0x10000 ) ) + 1) % 0x10000

这里的问题不是 ~ 有不同的含义。作为the documentation说,~x 返回“反转的x 的位”,这实际上与 C 中的意思相同(至少在 2s 补码平台上,包括所有 Windows平台)。

您可能会在这里遇到 C 和 Python 类型之间差异的问题(C 整数类型是固定大小的,并且会溢出;Python 整数类型实际上是无限大小的,并且会根据需要增长)。但我认为这不是你的问题。

问题只是如何将结果转换为字符串的问题。

调用 Checksum(Header) 的结果,在格式化之前,在两个版本中都是 -2299 或 -0x08fb。

在 C 中,您几乎可以将有符号整数视为相同大小的无符号整数(尽管在某些情况下您可能必须忽略警告才能这样做)。具体做什么取决于您的平台,但在 2s 补码平台上,有符号短 -0x08fb 是无符号 0xf705 的逐位等价物。因此,例如,如果您执行 sprintf(buf, "%04hx", -0x08fb),它工作得很好——并且它为您提供(在大多数平台上,包括 Windows 的所有平台)无符号等效项, f705

但是在 Python 中,没有无符号整数。 int -0x08fb 与 0xf705 无关。如果你执行 "%04hx"% -0x08fb,你将得到 -8fb,并且没有办法强制“将其转换为无符号”或类似的东西。

您的代码实际上执行 hex(-0x08fb),它为您提供 -0x8fb,然后您在 x 上拆分 ,给你 8fb,你将它 zfill08fb,这使得问题更难被注意到(因为它看起来像一对完全有效的十六进制字节,而不是减号和三个十六进制数字),但这是同样的问题。

无论如何,您必须明确决定“无符号等价物”的含义,并编写代码来做到这一点。由于您正试图匹配 C 在 2s 补码平台上所做的事情,因此您可以将该显式转换写为 % 0x10000。如果您执行 "%04hx"% (-0x08fb % 0x10000),您将获得 f705,就像您在 C 中所做的那样。对于您现有的代码也是如此。

关于c++ - 二进制 PLC 通信的校验和,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15914299/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com