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或192008数据位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.04ms3.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是BD引脚8是AD-。接线的时候要注意几点第一A接AB接B。虽然RS485标准里A和B的定义有时候会让人混淆但S7-200 SMART的引脚定义是明确的3脚是B8脚是A。被测设备如果是标准Modbus RTU设备通常也是A接A、B接B。如果不确定可以先接上试试通讯不上再调换。第二终端电阻的问题。如果被测总线两端已经有120Ω终端电阻侦听节点不要再加终端电阻否则总线负载会过重。如果总线没有终端电阻侦听节点可以加一个但要注意侦听节点通常位于总线中间某处加终端电阻反而不合适。我的做法是侦听节点不加终端电阻只做高阻抗监听。第三共地问题。RS485是差分信号理论上不需要共地但实际现场如果各设备地电位差较大可能会损坏接口。建议把侦听PLC的GND和被测总线的GND连接起来或者使用隔离型RS485中继器。实操心得我试过在一条已经接了5台变频器的总线上并联侦听PLC一开始没共地结果接收到的数据偶尔出现乱码。后来把GND连上乱码就消失了。所以共地这个事别偷懒。3.2 串口参数配置波特率、数据位、校验位S7-200 SMART的Freeport模式通过SMB30Port 0或SMB130Port 1来配置串口参数。以Port 0为例SMB30的各位定义如下位7-6校验选择。00无校验01偶校验10无校验11奇校验位5数据位。08位17位位4-2波特率。0003840000119200010960001148001002400101120011011520011157600位1-0协议选择。00PPI01Freeport10PPI11Freeport假设被测总线是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 024对应Port 1。当RCV指令完成时会触发中断。我利用这个中断来切换缓冲区标志通知主程序有新数据到达。主程序的工作是初始化串口和中断然后循环检测缓冲区标志。当标志置位时调用CRC计算子程序解析Modbus帧更新统计变量然后清除标志重新启动RCV指令。中断服务程序的工作很简单设置缓冲区切换标志记录接收到的字节数然后退出中断。不要在中断里做太多事情否则会影响下一次接收。3.4 Modbus RTU帧结构解析一个标准的Modbus RTU帧由四部分组成字段长度说明从站地址1字节1-2470为广播地址功能码1字节如03读保持寄存器06写单个寄存器数据域N字节根据功能码不同长度不同CRC校验2字节低字节在前高字节在后侦听到一帧数据后解析步骤是先检查长度是否至少4字节地址功能码CRC然后取最后两字节作为接收到的CRC对前面所有字节计算CRC对比两者是否一致。如果一致再根据功能码解析数据域如果不一致标记为CRC错误帧。3.5 常见功能码的数据域长度不同功能码的数据域长度不一样侦听程序需要能识别常见功能码才能正确判断帧是否完整。下面是我整理的常见功能码及其请求/应答帧长度功能码名称请求帧长度应答帧长度01读线圈8字节可变02读离散输入8字节可变03读保持寄存器8字节可变04读输入寄存器8字节可变05写单个线圈8字节8字节06写单个寄存器8字节8字节15写多个线圈可变8字节16写多个寄存器可变8字节对于读操作01-04应答帧的数据域第一个字节是字节数后面跟具体数据。所以应答帧总长度地址(1)功能码(1)字节数(1)数据(N)CRC(2)5N。侦听程序可以根据字节数推算出完整帧长。实操心得我在测试中发现有些变频器的Modbus应答帧不按标准来比如字节数写错了但CRC是对的。这种情况下如果严格按照字节数判断帧长会解析错误。所以侦听程序最好同时记录原始字节流人工复核。4. 实操过程与核心环节实现4.1 第一步硬件接线与串口初始化先把S7-200 SMART的Port 0通过RS485总线并联到被测总线上。我用的是DB9转接线3脚接B8脚接AGND接总线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存最大长度255VB101存实际接收长度VB102开始是数据。VB400是缓冲区B结构相同。4.2 第二步接收中断服务程序中断服务程序INT_0的作用是当RCV完成时记录当前缓冲区的实际接收长度切换缓冲区标志然后启动下一次RCV。// INT_0: 接收完成中断 // 判断当前使用的是哪个缓冲区 LD SM0.0 A M10.0 // M10.00表示当前用缓冲区A M10.1 // M10.11表示缓冲区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用的是缓冲区A1表示用的是缓冲区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 第四步帧解析与统计主程序在检测到新数据标志后执行以下步骤读取实际接收长度VB101或VB401如果小于4说明帧太短丢弃。取最后两字节作为接收到的CRC低字节在前。对前面所有字节计算CRC。对比计算出的CRC和接收到的CRC如果一致标记为有效帧否则标记为CRC错误帧。根据功能码解析数据域提取从站地址、功能码、数据内容。更新统计变量总帧数、有效帧数、错误帧数、各从站帧数等。统计变量我定义在VW200开始的区域变量地址含义VW200总接收帧数VW202有效帧数VW204CRC错误帧数VW206最近一帧的从站地址VW208最近一帧的功能码VW210最近一帧的CRC计算结果VW212最近一帧的接收CRC这些变量可以在状态图表中监控实时观察总线上的通讯情况。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 常见问题速查表现象可能原因排查方法接收不到数据接线错误检查A/B是否接反GND是否共地接收不到数据串口参数不匹配核对SMB30设置和总线参数接收不到数据RCV未启动监控RCV使能位检查中断程序数据乱码波特率不匹配确认双方波特率一致数据乱码校验位不匹配确认校验方式一致帧截断超时太短增大RCV超时时间帧粘连超时太长减小RCV超时时间CRC全错CRC算法错误用已知帧验证CRC子程序CRC全错字节序错误检查CRC高低字节顺序偶发CRC错总线干扰检查屏蔽线接地增加终端电阻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网络这种分布式侦听思路会很有价值。