工控人难题三：modbus延迟（1）
工控人难题系列
往期回顾
1 前言
近期在现场实际调试过程中出现了modbus通讯延迟问题。看门狗闪烁接收延迟，长时间不跳变。报警日志中持续出现VSD通讯中断报警。针对这个问题，进行了一次深度排查，还是介绍调试过程，重点讲解思路。
Modbus工控行业常用于和各类主从通讯，工控人多数情况是能通就行，并不能做到知其然，而知其所以然。在进阶之前，建议先看一下这篇基础贴。里边有modbus通讯常见的故障进行分析和通讯不稳定可能性列表。
《Modbus通讯常见故障处理》https://mp.weixin.qq.com/s/cJ-dMftJ8yHl91QS-lCyGw
新增
2 项目介绍
此项目是一个正常的机组项目本身分为UCS和ESD，带有多个子系统从站CCC、VSD、Bently同时又作为PCS系统的的从站，系统间的数据交互都是通过modbus。
PCS为modbusTCPIP 主站
CCC\VSD\Bently为modbusTCPIP 从站。
MCC为modbus485串口从站。
网络结构如下：
3 通讯故障现象介绍
项目一般我们会在系统通讯做一个0、1闪烁的心跳点每1秒钟闪烁一次，用来监视系统间通讯状态。这两个点闪烁正常同时能被UCS系统检测到，认为子系统通讯正常。
bCCC214watchdog_3A1
bVSD214watchdog_3A1
实际监测过程中发现这两个心跳信号经常中断，超过10秒，甚至30秒以上，证明系统间modbus通讯出现了不稳定现象。
4 测试机制搭建
4.1 搭建测试程序
为了监控和记录看门狗闪烁状态，特意搭建了一段程序，用于对watchdog闪烁点进行监控。搭建等程序是watchdog=1计时TIME1 、watchdog=0计时TIME2，并记录计算5次跳变的平均用时。
4.2 画面记录
通过画面监视记录看出modbus延迟TIME1、TIME2已经多次超过30S，无法满足通讯速率要求。
5 排查过程
5.1 PLC负载能力
产生这么大的通讯延迟，我首先想到的是不是子系统的通讯块和数据量太大了，超过了PLC的负载能力。毕竟很少有这么大的通讯站数。
从站的主副网通讯站数达到了49个。统计列表如下：
经过专业人士提供算式modbus轮询理论值计算如下：
3LCM卡用时时间2*27*100ms=5.4S
3RCM卡用时时间2*22*100ms=4.4S
所以T1=T2=5.4S modbus通讯的延迟不应大于5.4S。因此PLC的负载能力是没问题的，可以满足心跳信号在10S以内的轮询。
既然负载能力没问题，我们对照如下表格排查。这个表格来自我开篇介绍的入门神贴。
通讯接口松动、屏蔽双绞线，长度确认，电缆混拉，接口不匹配，设备老化都已排除。
1、 以太网丢包待查。
2、 一条通讯总线挂接不同的通讯设备存在。
3、 通讯节点太多存在。
5.2 以太网丢包
5.2.1 网络ping测
ping遍整个系统中所有网路，导出log日志，方法可回看《工控人难题一：网络冲突》。存在一定的ping网延迟，可接受而且并没有网络丢包。至少证明网路都是通的。
ping包中的延迟和modbus延迟故障判断不是一个层面上的内容。ping包使用的是ICMP命令，ping延迟不稳定只能表示网络中有冲突或者异常；这种异常反应到实际应用上有可能会造成网络丢包，导致PLC收不到从站应答。PLC对于从站是轮询的，轮询的周期就是上面公式计算出的时间；假如轮询需要5.4s，对于某个从站，如果有一次没有收到应答，等下一次收到应答就是间隔10.8s了，这个时间才是用于故障判断的时间。
5.2.2 Modscan工具扫描
用modscan扫描读取报文，看是否出现丢包现象。
ping网和modscan扫描都是正常的，测试后依然没有头绪。
5.3 一条通讯总线挂接不同的通讯设备
因为在NET2口中参与通讯的节点太多我们做如下测试。
1、CCC网线拔除，观测TIME1、TIME2。
2、Bently网线1拔除，观测TIME1、TIME2。
3、Bently网线2拔除，观测TIME1、TIME2。
4、VSD网线拔除，观测TIME1、TIME2。
这次排查有意外收获。发现VSD拔除后，所有的通讯都变好了。
6 VSD进一步排查
未完待续，下一期继续进行VSD专项排查。
大家有什么建议和支持测试方案请留言。
2025年06月
