No.

01 概述

Modbus RTU 是一种串行通信协议，由于具有协议透明，实现成本低，简单易用等诸多特点，至今仍然广泛应用在工业控制的各个领域。

为了通信可以长期稳定的运行，并且可以在故障时可以及时处理和排查，特梳理此文，用做参考学习使用。

诊断工作以 S7-1200/S7-1500 PLC的串口通信模块上的指示灯开始：

图1 LED指示灯

通过 RX/TX 指示灯的状态可以快速定位 Modbus RTU 通信故障，并且结合 Modbus RTU 通信指令状态代码，可以高效率地解决在现场中碰到的各类Modbus RTU 通信问题，故障诊断判断流程如图 2 所示。

图2 通信故障的判断流程图

作为 Modbus 主站，当与从站设备通信不上时，触发主站指令后，观察串口通信模块的 TX 指示灯是否闪烁：

作为 Modbus 从站，当与主站设备通信不上时，观察串口通信模块的 RX 指示灯是否闪烁：

No.

02 捕捉状态代码

由于 Modbus RTU 通信指令的状态代码仅持续一个扫描周期，直接在线监控无法实时看到，所以我们可以编写程序捕捉代码。

捕捉代码示例如图3所示。初始化指令、主站指令、从站指令均需捕捉状态代码。

图3 捕捉代码

No.

03 常见代码解读

16#80C8

该代码含义为：从站在设置时间内未响应，需要检查数据传输率、奇偶校验和从站的接线情况。

产生该代码的可能原因：

①接线错误。

在主从站接线时，很多用户习惯性的将设备间的 A 与 A，B 与 B 相连，进而组成总线式 RS485 网络，其实，正确方式为根据正负进行组网，应将设备间的正与正，负与负相连，因为并非所有设备的 A 为正，B 为负，如 CB1241 通信板，B 为正，A 为负，如图4所示。

图4 CB1241 通信接线

16#81Ex

该代码均指向字符帧错误，如16#81EA：字符帧过短，16#81E2：字符帧错误。

产生该代码的可能原因：

①  字符帧设置错误。

依次检查起始位、数据位、奇偶校验位、数据传输速率和结束位个数的设置是否一致。

其中，结束位的个数是在初始化指令的背景 DB 块中进行设置，默认为1个停止位。如图5所示。

图5 背景DB设置

② 字符间Zui大字符延迟时间 “ICHAR_GAP”

在 Modbus RTU 规约中， Modbus RTU 报文帧之间间隔不小于 3.5 个字符时间。如图6所示。

图6 Modbus RTU 报文帧以及间隔

西门子串口通信模块默认 Modbus RTU 报文帧结束的默认条件为 3.5 个字符时间。

假设波特率为 9600 bit/s，1 个起始位，1 个停止位，8 个数据位，1 个校验位，则 3.5 个字符时间为（1/9600）*1000*11*3.5=4 ms，不同波特率，对应的字符时间不同。

如果因为伙伴响应时间稍长、线路阻抗较大，或外界干扰等问题，Modbus RTU 报文帧中的字符间延时超过 3.5 个字符时间，则 PLC 会误认为报文帧结束，但实际并未结束，进而产生该类错误。

可以适当增大字符间Zui大字符延迟时间 “ICHAR_GAP”，避免该错误的发生，如图7所示。

图7 字符延迟时间

16#8280/16#8281

该代码含义为：读取/写入模块时失败，请检查 Port 参数的输入。

产生该代码的可能原因：

① 初始化指令 Port 管脚输入错误

初始化指令 Port 管脚应输入串口通信模块的硬件标识符，错误的硬件标识符将导致初始化失败。

② 未指定工作模式

应在初始化指令的背景 DB 块 Mode 参数中，指定串口通信模块的工作模式，模式 4 为半双工（RS485）两线模式，如图 8 所示，下载程序后断电重启生效。不同的 Mode 数值代表不同的工作模式，如表 1所示。

该设置仅适用于 Modbus（RTU）指令集，不适用 Modbus 指令集。

图8 DB块模式

表1 各种模式列表

总结：

以上内容是针对经常出现的 S7-1200/1500 Modbus RTU 通信故障的处理总结，其它更多的工业通信技术以及经验分享，敬请访问西门子 1847 工业学习平台，让我们一同学习，共同成长！