S7-200 SMART PLC实现Modbus RTU总线数据侦听与故障诊断

1. 项目缘起：为什么要做Modbus RTU数据侦听

搞工控的兄弟大多遇到过这种场景：现场一台S7-200 SMART PLC通过RS485总线和几台变频器、仪表或者第三方设备通讯，运行一段时间后数据偶尔跳变，或者干脆通讯中断。你打开STEP 7-Micro/WIN SMART监控程序，发现PLC发出去的指令没问题，但返回的数据就是不对。这时候问题就来了——到底是PLC的Modbus主站指令有问题，还是从站设备返回的数据本身就有毛病，又或者是RS485链路上有干扰导致数据帧被破坏？

常规做法是拿个USB转RS485的转换器，接到总线上去抓包。但很多时候现场条件不允许你随便挂设备，尤其是已经投运的生产线，你不可能把PLC停下来让你慢慢接线。而且有些现场根本没有笔记本可以带进去，或者你手头只有一台PLC，没有专用的协议分析仪。

这时候“侦听”这个思路就派上用场了。所谓侦听，就是让S7-200 SMART PLC自己变成一个“旁听者”，它不主动发起Modbus请求，只是被动地接收总线上流动的数据，把原始字节流记录下来，然后通过程序解析出Modbus RTU的帧结构，判断CRC校验是否正确，从而定位问题到底出在哪一环。

这个测试方案的核心价值在于：不需要额外硬件，不需要中断生产，利用手头现有的S7-200 SMART PLC就能完成对Modbus RTU总线的数据侦听和故障诊断。它适合那些已经有一定PLC编程基础、正在调试或维护Modbus RTU通讯链路的工控从业者，也适合刚接触S7-200 SMART和Modbus协议、想深入理解协议底层帧结构的技术人员。

我这次做的测试，就是在一块S7-200 SMART SR20上，利用它的RS485端口（Port 0），配合Freeport自由口通讯模式，实现对总线上Modbus RTU数据的侦听、缓存、解析和CRC校验，最终把结果通过状态指示灯或者变量表呈现出来。整个过程不需要任何额外的硬件设备，只需要一根RS485总线连接线，把PLC的通讯口并联到被测总线上即可。

下面我把整个项目的设计思路、关键细节、实操步骤和踩过的坑，完整地梳理一遍。

2. 整体设计思路与方案选型

2.1 为什么选择Freeport模式而不是Modbus主站指令

S7-200 SMART本身支持两种Modbus通讯方式：一种是调用库里的MBUS_CTRL和MBUS_MSG指令，作为Modbus主站主动发起请求；另一种是使用Freeport自由口模式，通过XMT和RCV指令自己控制串口的收发。

做侦听只能用Freeport模式，原因很简单：MBUS_MSG指令是“请求-应答”模式，它发一条指令出去，然后等从站回复，整个过程是主动的、有状态的。而侦听需要的是“只收不发”，被动地监听总线上所有数据。Freeport模式下的RCV指令可以配置为接收任意字节，不关心数据内容，正好满足这个需求。

具体来说，我把Port 0配置为Freeport模式，波特率、数据位、停止位、校验方式都设置成和被测总线一致（通常是9600或19200，8数据位，1停止位，无校验或偶校验）。然后循环调用RCV指令，把接收到的每一个字节存入一个缓冲区。当检测到帧间隔（3.5个字符时间）后，认为一帧数据接收完毕，开始解析。

2.2 缓冲区设计：环形缓冲还是线性缓冲

侦听过程中数据是连续不断的，如果只用一个固定长度的线性缓冲区，很快就会溢出。我最初的想法是用环形缓冲区，但S7-200 SMART的间接寻址和指针操作相对有限，实现复杂的环形缓冲逻辑会比较绕。

最终我选择了一个折中方案：双缓冲区交替使用。定义两个接收缓冲区，每个缓冲区长度设为256字节（足够容纳一帧最长的Modbus RTU数据，标准Modbus RTU帧最大256字节）。当缓冲区A在接收数据时，缓冲区B可以被主程序解析；接收完一帧后切换。这样既避免了数据覆盖，又不需要复杂的环形指针运算。

注意：S7-200 SMART的RCV指令每次最多接收255字节，所以缓冲区长度不要超过255，否则需要分段接收。

2.3 CRC校验的实现方式

Modbus RTU的CRC校验是16位的，多项式为0xA001（反向的0x8005）。在S7-200 SMART上实现CRC计算有两种方式：查表法和逐位计算法。

查表法速度快，但需要预先生成一个256项的CRC表，占用较多存储空间。逐位计算法代码简单，但每次计算需要循环8次，对于侦听这种非实时性要求极高的场景来说完全够用。我选择了逐位计算法，用STL或者SCL写一个CRC计算子程序，输入是数据缓冲区指针和数据长度，输出是计算出的CRC值。

计算过程是这样的：初始化CRC寄存器为0xFFFF，然后对每个字节，先与CRC寄存器的低字节异或，然后循环8次，每次判断最低位是否为1，如果是则右移一位后异或0xA001，否则只右移一位。最后得到的CRC值低字节在前、高字节在后，与接收到的CRC字节对比。

2.4 帧间隔判断：3.5字符时间的实现

Modbus RTU协议规定，帧与帧之间至少要有3.5个字符时间的静默间隔。在波特率9600下，一个字符时间是10位（1起始位+8数据位+1停止位），即10/9600≈1.04ms，3.5个字符时间约3.64ms。在19200下约1.82ms。

S7-200 SMART的RCV指令有超时参数，可以设置一个超时时间。当总线静默超过这个时间后，RCV指令会结束并置位完成标志。我利用这个特性来判断帧结束：设置RCV的超时时间为4ms（对应9600波特率下的3.5字符时间），当RCV完成时，认为一帧数据接收完毕。

但这里有个细节：如果总线上数据帧比较密集，帧间隔可能刚好卡在3.5字符时间附近，容易误判。我的做法是稍微放宽超时时间到5ms，牺牲一点实时性换取稳定性。实测下来，对于常见的Modbus RTU轮询周期（通常几十毫秒到几百毫秒），5ms的超时完全不会把两帧数据粘在一起。

2.5 数据呈现方式

侦听到的数据需要呈现出来才能分析。S7-200 SMART没有屏幕，所以我设计了两种输出方式：

第一种是通过PLC的状态指示灯（RUN/STOP/ERROR）来粗略指示。比如接收到有效帧时RUN灯闪烁，CRC错误时ERROR灯闪烁。这种方式简单但信息量有限。

第二种是通过变量表监控。在STEP 7-Micro/WIN SMART软件中，把接收缓冲区、CRC计算结果、帧计数等变量添加到状态图表中，实时监控。这种方式信息量大，但需要电脑连接PLC。

第三种是通过串口发送到上位机。把解析后的数据通过Port 1（如果PLC有两个串口）或者同一个Port 0发送出去，但这样会干扰侦听。所以实际测试中我主要用变量表监控的方式。

3. 核心细节解析与实操要点

3.1 硬件连接：RS485总线并联的注意事项

侦听的前提是PLC的RS485端口要并联到被测总线上。S7-200 SMART的Port 0是RS485接口，DB9母头，引脚3是B（D+），引脚8是A（D-）。

接线的时候要注意几点：

第一，A接A，B接B。虽然RS485标准里A和B的定义有时候会让人混淆，但S7-200 SMART的引脚定义是明确的：3脚是B，8脚是A。被测设备如果是标准Modbus RTU设备，通常也是A接A、B接B。如果不确定，可以先接上试试，通讯不上再调换。

第二，终端电阻的问题。如果被测总线两端已经有120Ω终端电阻，侦听节点不要再加终端电阻，否则总线负载会过重。如果总线没有终端电阻，侦听节点可以加一个，但要注意侦听节点通常位于总线中间某处，加终端电阻反而不合适。我的做法是侦听节点不加终端电阻，只做高阻抗监听。

第三，共地问题。RS485是差分信号，理论上不需要共地，但实际现场如果各设备地电位差较大，可能会损坏接口。建议把侦听PLC的GND和被测总线的GND连接起来，或者使用隔离型RS485中继器。

实操心得：我试过在一条已经接了5台变频器的总线上并联侦听PLC，一开始没共地，结果接收到的数据偶尔出现乱码。后来把GND连上，乱码就消失了。所以共地这个事，别偷懒。

3.2 串口参数配置：波特率、数据位、校验位

S7-200 SMART的Freeport模式通过SMB30（Port 0）或SMB130（Port 1）来配置串口参数。以Port 0为例，SMB30的各位定义如下：

• 位7-6：校验选择。00=无校验，01=偶校验，10=无校验，11=奇校验
• 位5：数据位。0=8位，1=7位
• 位4-2：波特率。000=38400，001=19200，010=9600，011=4800，100=2400，101=1200，110=115200，111=57600
• 位1-0：协议选择。00=PPI，01=Freeport，10=PPI，11=Freeport

假设被测总线是9600波特率、8数据位、无校验，那么SMB30应该设置为2#00001001，即16#09。如果是19200、8数据位、偶校验，则是2#00100101，即16#25。

配置完SMB30后，还需要设置RCV指令的参数。RCV指令的格式是：RCV TBL, PORT。其中TBL是一个缓冲区，第一个字节是接收的最大字节数，第二个字节是实际接收到的字节数，后续字节是接收到的数据。

注意：RCV指令的TBL缓冲区第一个字节必须预先填入最大接收长度，否则RCV指令会报错。

3.3 接收中断与主程序的分工

S7-200 SMART的Freeport模式支持接收完成中断（中断号23对应Port 0，24对应Port 1）。当RCV指令完成时，会触发中断。我利用这个中断来切换缓冲区标志，通知主程序有新数据到达。

主程序的工作是：初始化串口和中断，然后循环检测缓冲区标志。当标志置位时，调用CRC计算子程序，解析Modbus帧，更新统计变量，然后清除标志，重新启动RCV指令。

中断服务程序的工作很简单：设置缓冲区切换标志，记录接收到的字节数，然后退出中断。不要在中断里做太多事情，否则会影响下一次接收。

3.4 Modbus RTU帧结构解析

一个标准的Modbus RTU帧由四部分组成：

侦听到一帧数据后，解析步骤是：先检查长度是否至少4字节（地址+功能码+CRC），然后取最后两字节作为接收到的CRC，对前面所有字节计算CRC，对比两者是否一致。如果一致，再根据功能码解析数据域；如果不一致，标记为CRC错误帧。

3.5 常见功能码的数据域长度

不同功能码的数据域长度不一样，侦听程序需要能识别常见功能码，才能正确判断帧是否完整。下面是我整理的常见功能码及其请求/应答帧长度：

对于读操作（01-04），应答帧的数据域第一个字节是字节数，后面跟具体数据。所以应答帧总长度=地址(1)+功能码(1)+字节数(1)+数据(N)+CRC(2)=5+N。侦听程序可以根据字节数推算出完整帧长。

实操心得：我在测试中发现，有些变频器的Modbus应答帧不按标准来，比如字节数写错了但CRC是对的。这种情况下，如果严格按照字节数判断帧长，会解析错误。所以侦听程序最好同时记录原始字节流，人工复核。

4. 实操过程与核心环节实现

4.1 第一步：硬件接线与串口初始化

先把S7-200 SMART的Port 0通过RS485总线并联到被测总线上。我用的是DB9转接线，3脚接B，8脚接A，GND接总线GND。接线完成后，给PLC上电，用网线连接电脑和PLC，打开STEP 7-Micro/WIN SMART软件，扫描到PLC。

然后在系统块里配置Port 0的参数。虽然Freeport模式下SMB30会覆盖系统块设置，但为了保险起见，我还是在系统块里把Port 0的波特率设为9600、8数据位、无校验，和被测总线一致。

接下来写初始化程序。在第一个扫描周期（用SM0.1触发），执行以下操作：

// 初始化Port 0为Freeport模式，9600,8,N,1 MOVB 16#09, SMB30 // 初始化接收缓冲区A MOVB 255, VB100 // 最大接收长度 MOVB 0, VB101 // 实际接收长度清零 // 初始化接收缓冲区B MOVB 255, VB400 MOVB 0, VB401 // 连接接收完成中断 ATCH INT_0, 23 ENI // 启动第一次接收 RCV VB100, 0

这段代码里，VB100是缓冲区A的起始地址，VB100存最大长度255，VB101存实际接收长度，VB102开始是数据。VB400是缓冲区B，结构相同。

4.2 第二步：接收中断服务程序

中断服务程序INT_0的作用是：当RCV完成时，记录当前缓冲区的实际接收长度，切换缓冲区标志，然后启动下一次RCV。

// INT_0: 接收完成中断 // 判断当前使用的是哪个缓冲区 LD SM0.0 A M10.0 // M10.0=0表示当前用缓冲区A = M10.1 // M10.1=1表示缓冲区A有新数据 // 切换缓冲区标志 LD SM0.0 X M10.0, M10.0 // 翻转M10.0 // 根据新的缓冲区标志启动下一次RCV LD M10.0 RCV VB400, 0 LDN M10.0 RCV VB100, 0

这段逻辑有点绕，我解释一下：M10.0是缓冲区选择标志，0表示当前RCV用的是缓冲区A，1表示用的是缓冲区B。中断发生时，说明当前缓冲区的RCV完成了，数据已经存进去了。然后翻转M10.0，用另一个缓冲区启动新的RCV。同时，M10.1置位表示缓冲区A有新数据，M10.2置位表示缓冲区B有新数据。

主程序检测到M10.1或M10.2置位后，就调用解析子程序处理对应的缓冲区。

4.3 第三步：CRC计算子程序

CRC计算是侦听程序的核心。我用SCL写了一个CRC计算函数，输入是数据起始地址和长度，输出是CRC值。

FUNCTION_BLOCK CRC16 VAR_INPUT pData : DWORD; // 数据起始地址 Len : INT; // 数据长度 END_VAR VAR_OUTPUT CRC : WORD; // 计算结果 END_VAR VAR_TEMP i : INT; j : INT; temp : BYTE; END_VAR BEGIN CRC := 16#FFFF; FOR i := 0 TO Len - 1 DO temp := BYTE_TO_BYTE(*(pData + i)); CRC := CRC XOR temp; FOR j := 0 TO 7 DO IF (CRC AND 16#0001) <> 0 THEN CRC := (CRC / 2) XOR 16#A001; ELSE CRC := CRC / 2; END_IF; END_FOR; END_FOR; END_FUNCTION_BLOCK

注意：S7-200 SMART的SCL编译器对指针运算支持有限，上面代码中的*(pData + i)在实际编译时可能需要用间接寻址的方式实现。如果SCL编译不过，可以改用STL写。

用STL实现CRC计算的思路类似，用指针寄存器（如&VB100）和循环计数器，逐字节处理。STL代码虽然不如SCL直观，但在S7-200 SMART上兼容性更好。

4.4 第四步：帧解析与统计

主程序在检测到新数据标志后，执行以下步骤：

1. 读取实际接收长度（VB101或VB401），如果小于4，说明帧太短，丢弃。
2. 取最后两字节作为接收到的CRC（低字节在前）。
3. 对前面所有字节计算CRC。
4. 对比计算出的CRC和接收到的CRC，如果一致，标记为有效帧；否则标记为CRC错误帧。
5. 根据功能码解析数据域，提取从站地址、功能码、数据内容。
6. 更新统计变量：总帧数、有效帧数、错误帧数、各从站帧数等。

统计变量我定义在VW200开始的区域：

这些变量可以在状态图表中监控，实时观察总线上的通讯情况。

4.5 第五步：测试验证

为了验证侦听程序是否正常工作，我先用一台S7-200 SMART作为Modbus主站，另一台作为从站，模拟正常的Modbus RTU通讯。主站用MBUS_MSG指令读取从站的保持寄存器，从站用MBUS_INIT和MBUS_SLAVE指令响应。

然后把侦听PLC并联到这条总线上，观察变量表。正常情况下，应该能看到总帧数不断增加，有效帧数占总帧数的比例接近100%，CRC错误帧数为0。

接着我人为制造一些异常：比如把波特率改错，观察CRC错误帧数是否增加；比如在总线上加一个干扰源，观察错误帧的变化。实测下来，波特率不匹配时，接收到的数据完全是乱码，CRC错误率100%。总线干扰较强时，偶发CRC错误，错误率在1%以下。

实操心得：测试的时候最好先用短距离、干净的通讯环境验证程序逻辑，确认程序没问题后，再到现场实际总线上测试。否则现场问题复杂，你分不清是程序bug还是现场干扰。

4.6 第六步：现场部署与长期监测

程序验证通过后，就可以部署到现场了。把侦听PLC接到现场总线上，上电运行。由于侦听PLC只收不发，不会对总线造成任何影响，所以可以长期挂载。

我通常会把侦听PLC的网口接到现场交换机上，然后通过上位机软件（如WinCC或第三方组态软件）远程监控变量表。这样不用到现场就能看到总线通讯状态。

如果需要记录历史数据，可以在上位机上做一个简单的数据记录功能，把总帧数、错误帧数等变量按时间戳存入数据库，方便事后分析。

5. 常见问题与排查技巧实录

5.1 接收不到任何数据

这是最常见的问题。排查思路如下：

第一，检查硬件接线。A和B有没有接反？GND有没有共地？总线两端终端电阻是否合适？我遇到过好几次都是A、B接反了，调换一下就好了。

第二，检查串口参数。SMB30设置的波特率、数据位、校验位是否和被测总线一致？如果被测总线是19200，你设成9600，那接收到的全是乱码，而且RCV可能根本完不成。

第三，检查RCV指令是否启动。在状态图表里监控RCV指令的使能位和完成位，确认RCV在循环执行。如果RCV只执行了一次就停了，说明中断程序里没有重新启动RCV。

第四，检查中断是否连接。用ATCH指令连接中断后，必须执行ENI指令全局使能中断。如果忘了ENI，中断永远不会触发。

5.2 数据帧被截断或粘连

帧截断通常是因为RCV的超时时间设得太短，一帧数据还没接收完就超时结束了。解决办法是适当增大超时时间。在9600波特率下，我一般设5-10ms。

帧粘连是因为超时时间设得太长，两帧数据之间的间隔小于超时时间，RCV把两帧当成一帧接收了。解决办法是减小超时时间，但不要小于3.5字符时间。

如果现场总线负载很高，帧间隔很小，可以考虑用字符间隔超时而不是固定超时。但S7-200 SMART的RCV指令只支持固定超时，所以只能折中。

5.3 CRC校验总是失败

如果所有帧的CRC都失败，首先检查CRC计算子程序是否正确。可以用已知的Modbus帧测试，比如01 03 00 00 00 01 84 0A，正确的CRC应该是0x0A84（低字节0x84在前，高字节0x0A在后）。

如果CRC计算正确但接收到的CRC不对，检查接收缓冲区的数据是否完整。有时候RCV接收到的字节数比实际帧长度少，导致CRC字节没接收到。

还有一种可能是字节序问题。Modbus RTU的CRC是低字节在前、高字节在后，计算出来的CRC如果直接比较，需要把高低字节调换。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个坑：RCV缓冲区第一个字节必须预填最大长度。我刚开始做的时候忘了填，RCV指令直接报错，折腾了半天才发现。这个细节在S7-200 SMART手册里写得很清楚，但容易忽略。

第二个坑：中断程序里不要做耗时操作。我一开始在中断里直接调用CRC计算和帧解析，结果中断执行时间太长，影响了下一次RCV的启动，导致丢帧。后来改成中断只设标志，主程序做解析，问题解决。

第三个坑：双缓冲区切换时要注意数据一致性。主程序在解析缓冲区A的时候，中断可能已经把缓冲区B的数据准备好了。如果主程序解析完A后没有及时清除标志，可能会重复解析同一帧数据。我的做法是解析前先清除标志，解析完再检查标志是否又被置位。

第四个坑：波特率高于38400时侦听不稳定。S7-200 SMART的Freeport模式在高速波特率下，RCV指令的响应时间可能跟不上，导致丢帧。如果被测总线波特率是115200，建议换用专用的协议分析仪，不要用PLC侦听。

第五个坑：现场总线上的设备地址冲突。侦听的时候如果发现两个不同从站地址的帧交替出现，但功能码和数据域完全一样，可能是两个设备地址设成了同一个。这种情况在调试阶段很常见，侦听程序能帮你快速发现。

6. 侦听方案的扩展与优化

6.1 增加时间戳记录

基本的侦听程序只记录帧内容和CRC结果，不记录时间。如果要分析通讯的实时性，比如主站轮询周期是否稳定，就需要给每帧数据打上时间戳。

S7-200 SMART没有实时时钟指令可以直接读取毫秒级时间，但可以用定时器累加。比如用一个10ms的定时器T32，每10ms中断一次，累加一个双字变量作为时间基准。接收到帧时，把当前时间基准值存入帧记录缓冲区。

这样就能分析出每帧之间的时间间隔，判断主站轮询是否超时、从站响应是否及时。

6.2 增加数据记录与导出

S7-200 SMART的存储区有限，不可能记录大量历史数据。我的做法是只记录最近N帧（比如100帧）的摘要信息，包括时间戳、从站地址、功能码、CRC结果。当需要详细分析时，再把原始字节流导出到上位机。

导出方式可以通过串口发送到上位机，或者通过以太网用TCP通讯发送。S7-200 SMART支持开放式以太网通讯，可以用TCP_CONNECT和TCP_SEND指令把数据发到上位机的TCP服务器。

6.3 多从站通讯质量统计

如果总线上有多个从站，可以按从站地址分别统计通讯质量。比如从站1的总帧数、错误帧数、平均响应时间等。这样能快速定位是哪个从站的通讯有问题。

实现方法是在帧解析时，根据从站地址把统计变量索引到不同的存储区。比如从站1的统计变量在VW300开始，从站2的在VW320开始，以此类推。

6.4 与上位机组态软件集成

侦听PLC的变量可以通过以太网被上位机组态软件（如WinCC、组态王、Kepware等）读取。在上位机上做一个监控画面，实时显示总线通讯状态、错误率、各从站通讯质量等。

如果错误率超过阈值，可以触发报警，提醒运维人员检查。这样就把一个被动的侦听工具变成了一个主动的通讯质量监控系统。

6.5 侦听方案的局限性

这个方案虽然实用，但也有一些局限性需要说明：

第一，S7-200 SMART的Freeport模式在波特率高于38400时侦听稳定性下降，高速总线建议用专用工具。

第二，侦听程序占用PLC的通讯资源，如果PLC本身还要做其他通讯任务，可能会互相影响。建议用一台独立的PLC专门做侦听。

第三，侦听只能看到总线上的数据，看不到主站内部的请求逻辑。如果主站发出的请求本身就是错的，侦听只能告诉你“请求错了”，但不能告诉你“为什么错”。

第四，对于Modbus ASCII模式或者Modbus TCP，这个方案不适用。Modbus ASCII的帧结构和RTU不同，Modbus TCP是以太网协议，需要另外的方案。

7. 个人实操体会与建议

我在多个现场用过这个侦听方案，有成功的经验，也有踩坑的教训。最大的体会是：侦听程序本身不复杂，复杂的是现场环境的适应。同样的程序，在实验室里跑得好好的，到了现场可能因为接线、干扰、参数不匹配等各种原因出问题。所以现场调试的时候，一定要有耐心，一步一步排查。

另外，侦听只是手段，不是目的。目的是通过侦听数据定位通讯故障的根因。我见过有些兄弟抓了一堆数据，但不知道怎么分析，最后还是没解决问题。所以建议在做侦听之前，先想清楚你要回答什么问题：是主站请求有问题，还是从站响应有问题，还是链路干扰导致数据损坏？带着问题去侦听，效率会高很多。

最后分享一个小技巧：如果现场没有条件用电脑监控变量表，可以把侦听结果通过PLC的RUN/STOP/ERROR指示灯编码输出。比如RUN灯闪1次表示有效帧，闪2次表示CRC错误帧，ERROR灯常亮表示通讯中断。虽然信息量有限，但至少能让你在不接电脑的情况下知道总线是否正常。

这个方案后续还可以扩展成多PLC分布式侦听，比如在总线的不同位置各挂一台侦听PLC，对比不同位置的接收情况，就能判断干扰源大概在哪个区段。对于大型RS485网络，这种分布式侦听思路会很有价值。