未知CRC方法

Question

01 37 37 1D 31 31 31 1D 30 1D 31 03 32 35 30 34 39 04
01 37 37 1D 31 31 31 1D 30 1D 32 03 32 35 30 34 33 04
01 37 37 1D 31 31 31 1D 30 1D 33 03 35 37 38 31 34 04
01 37 37 1D 31 31 31 1D 30 1D 34 03 32 35 30 33 31 04
01 37 37 1D 31 31 31 1D 30 1D 35 03 35 37 37 39 34 04

对于上面的modbus轮询查询，我没有得到哪个是crc值，以及使用了什么类型的crc。它是怎么来的，77是设备的id。请指引我。

我从轮询设备得到以下响应

01 37 37 02 33 1D 30 39 33 31 39 30 39 34 38 32 30 30 37 31 31 42 20 30 30 30 
30 30 30 30 38 34 30 30 30 30 30 30 30 30 30 30 30 30 30 30 37 38 30 30 30 30 
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 33 35 31 30 30 30 30 30 
30 30 30 30 30 30 30 30 30 30 30 30 30 30 03 34 37 33 38 35 04

Answer 1

首先：

• Modbus over Serial Line标准可在此处获得。这完全指定了到Modbus的低级接口。
• Modbus应用程序协议规范在这里提供。此处指定了更高级别的MODBUS命令。
• 这两个标准都相当简短，易于阅读和理解，并且包含很好的图表，所以我强烈建议您查看它们以获得答案。

您的数据似乎不符合这些标准，这使得很难回答您的问题！

• RTU通信方法是唯一使用CRC的通信方法。ASCII通信方法使用纵向冗余检查(LRC)，这是不同的。
• RTU通信方法使用CRC-16，这意味着CRC有16位=2字节。详细信息包含在串行线标准中，甚至有一些用于计算CRC的示例C代码。如果您使用谷歌，也有多种语言的多种实现，但一定要小心，因为有几种不同的CRC-16定义，您需要确保使用的内容符合MODBUS标准。
• MODBUS帧中的CRC位置位于帧的最末端。最后两个字节（16位）是CRC。首先追加CRC的低阶字节，然后追加高阶字节。
• 您提供的MODBUS查询似乎根本没有附加CRC。但是，正如我前面提到的，您提供的MODBUS查询看起来甚至不像是使用RTU通信方法，这是唯一使用CRC的方法。

由于您的数据似乎不遵循RTU通信方法，可能它使用ASCII通信方法，从串行线标准第16页开始描述。ASCII通信方法始终以ASCII:字符开始，该字符以十六进制表示为3A。ASCII通信方法始终以ASCII cr和lf字符结尾，它们是0d和0a（十六进制）。这些字符之间的所有其他字符必须是0-9或A-F字符，它们是30到39和41到46（十六进制）。您的消息不符合任何这些要求--它不以3a开头，不以0d0a结尾，并且它包含的其他字符不是30到39或41到46。

如果我们忽略这一点，并假设您的数据遵循ASCII通信方法，那么：

• LRC字段将是末尾0d0a之前的最后两个字节。
• 串行线标准第18页描述了如何计算LRC。非常简单:

The LRC is calculated by adding together successive 8–bit bytes of
the message, discarding any carries, and then two’s complementing the
result.  It is performed on the bytes of the message, before the
encoding of each byte in the two ASCII characters corresponding to the
hexadecimal representation of each nibble.  The computation does not include
the 'colon' character that begins the message, and does not include the CRLF
pair at the end of the message.  The resulting LRC is ASCII encoded into two
bytes and placed at the end of the ASCII mode frame before the CRLF.

• 串行线标准第38页给出了生成LRC的C代码示例。只有9行代码。

您的数据不遵循这两种通信方法中的任何一种。我们需要更多地了解您的数据来自哪里，以找出哪里出了问题。也许数据被多个设备损坏了，或者测量数据的传感器有不正确的定时或电压或其他原因，导致它错误地理解发送的值。可能存在某种奇偶校验不匹配，导致某些字节被丢弃。但如果没有更多的信息我们就无法判断。