1. 从一台设备重启开始的“全站轮询停滞”1.1 现象Modbus Poll读得好好的PLC就是读不到去年我接过一个项目现场是S7-1200通过Modbus TCP轮询4台从站设备设备端是温控器、变频器和一台小型仪表IP地址分配得很规矩网段、端口、寄存器表都清清楚楚。程序写完后单台调试、四台联调都通过了数据刷新也稳定我当时觉得这个项目稳了。结果没过多久现场反馈了一个特别诡异的现象3号温控器因为供电回路跳闸突然断电送电重启之后整个系统的4台从站全部读不回来。而且不是读一次超时、下次自愈那种是一直读不回来直到把PLC也断电重启系统才恢复正常。我赶到现场第一反应是轮询逻辑写串了或者从站重启后IP地址变了。但打开电脑上的Modbus Poll填上IP地址、端口502、功能码03一路读过去每个寄存器清清楚楚数据完全正常。也就是说同一台交换机、同一台设备、同一个IP调试软件能读PLC读不回来。这种“软件正常、PLC异常”的现象在Modbus TCP项目里其实比很多人想象的更常见。我花了一整天换过轮询周期、换过超时时间、改过寄存器地址映射全部没用。最后把Wireshark挂上抓包看着报文才明白问题根本不在Modbus的应用层而藏在了TCP的连接层。这个坑不是改几个地址参数能绕开的它直指Modbus TCP整个协议栈在工业现场使用时的结构性弱点。1.2 第一轮排查字节序、寄存器地址、功能码都试过那次现场排查其实把我所有“常规武器”都打光了。先检查了IP和端口配置。4台从站的IP我都重新ping过通没有冲突。接着查寄存器地址映射拿PLC里读回来的原始值和Modbus Poll的读值做对比发现根本不是偏移量的问题——因为PLC那边连一个正常响应都拿不到不是“数据值不对”是“没有响应”。再查功能码文档上说3号温控器的温度寄存器是03功能码的保持寄存器我用Modbus Poll验证过同一功能码没有问题。然后我开始怀疑轮询节奏。S7-1200这边我用了一个MB_CLIENT块顺序轮询4台设备每台之间留了50ms间隔请求超时设置500ms。当时怀疑是不是请求间隔太短导致从站处理不过来。把间隔从50ms加到了300ms结果没用又把超时从500ms加到2000ms还是没用。最后把电脑的防火墙关掉、交换机端口重启、PLC程序重新下载统统试了一遍故障依旧。唯一有效的手段就是把PLC断电重启——这也是现场操作的“终极办法”但只要再重复一次“3号从站断电重启”故障就会再次出现。这个“稳定复现”的规律其实已经给了我很大提示问题一定和3号从站的TCP连接状态有关。但在当时我对Modbus TCP的理解还停留在“IP端口寄存器地址”这个层面没有意识到连接层状态的破坏会直接让整个应用层的轮询全部失效。这篇博文想聊的就是我把这个坑彻底刨开后的完整认识。2. 表面坑排雷这些坑够常见但都算不上“最深”2.1 字节序/字序错乱同一个地址四种不同的解释Modbus协议本身传输的是16位寄存器数据以大端字节序排列也就是一个寄存器里高字节在前、低字节在后。这个规则本身不算复杂复杂的是寄存器数据跨两个16位时的排列方式比如32位浮点数。不同厂商的设备存储一个32位浮点值时可能是“寄存器顺序正序、寄存器内字节大端”也可能是“寄存器顺序正序、寄存器内字节小端”甚至可能“寄存器顺序反序但字节序正常”一共存在四种排列。大部分新手看到读回来的数据是零或者一个天文数字第一反应就是公式算错了其实是字节序没对上。举个例子一个温度值100.5按IEEE754浮点数存成32位拆成两个寄存器后有的设备里存成第一寄存器0x42C9第二寄存器0x0000有的设备则存成第一寄存器0x0000第二寄存器0x42C9还有的在寄存器内部把高低字节交换在S7-1200里MB_CLIENT读回来的原始数据直接就进到DB块你需要根据从站文档或者实测结果用字交换、字节交换指令把数据调整成程序能直接用的人性化数据。这个坑好解决因为拿Modbus Poll或者直接看原始寄存器值就能对比出来属于“半小时能定位”的范畴。2.2 寄存器地址偏移文档地址与协议地址永远差的那个“1”字节序坑后面还有一个隐藏很深的细节就是地址偏移。很多设备的寄存器手册习惯用“40001、40002”这种PLC风格的地址来描述第一个保持寄存器叫40001。但Modbus TCP协议报文里功能码03后面跟的起始地址是从0开始的也就是说手册上的40001对应协议地址040002对应协议地址1。如果你直接把手册上的40001填进上位机或者PLC的起始地址参数里读回来的是第二个寄存器。少数现场设备就差这1个寄存器导致温度、压力、频率全部错位换算出来完全不是现场值。更麻烦的是有些工具在界面上能切换“PLC地址”和“协议地址”两种显示模式配置的时候混用了排查起来很容易绕晕。S7-1200的MB_CLIENT指令DATA_ADDR参数用的是协议地址不是PLC地址这个在官方帮助文档里有写但现场很多人第一遍都不会细看。好在这种坑同样不影响连接只影响数据内容抓包对比请求报文和响应报文就能确认。2.3 功能码和寄存器类型混用03、04、01、02的语义差异Modbus TCP的功能码我列一下最常见的几个功能码含义访问类型01读线圈位读写02读离散输入位只读03读保持寄存器字读写04读输入寄存器字只读05写单个线圈位06写单个寄存器字15写多个线圈位16写多个寄存器字03和04是最容易混的。有的设备手册上只写“寄存器号”不区分用途再加上部分设备把只读参数放在输入寄存器里把可写参数放在保持寄存器里你一旦用错了功能码请求会成功返回但返回的值可能恒为0或者完全对不上。更迷惑的是有些设备对不存在的功能码会回异常有些则把所有功能码都当作03处理这就更坑了。我的经验是接到一个新设备后先用Modbus Poll把03、04、01、02各扫一遍确认哪些地址有数据、哪些报异常再据此确定PLC里的功能码配置。别依赖厂家文档上的“寄存器表”去做一字不差的翻译文档经常滞后于固件版本。2.4 把“轮询间隔”当成“从站响应时间”的偏差设备通信正常后还有一类表面坑和时序有关。串行轮询有一个基础约束同一时刻只能有一个请求在等响应。所以你的轮询周期不是“每台设备响应时间之和”而是“每台设备响应时间之和加上可能发生的超时时间之和”。这个公式我在第4部分会详细展开这里先提一个容易误解的点很多人把Modbus Poll里的轮询间隔设置当成从站的响应时间参考这是不对的。Modbus Poll在PC上跑的时候间隔设小一点比如10ms通常也能正常读但这不代表PLC用10ms间隔也正常。从站的响应速度受其CPU负载、通信任务调度、TCP栈处理能力影响PC的协议栈处理线程和PLC的任务周期完全不是一回事。我自己就见过一台变频器Modbus Poll用20ms间隔能连续读几百次不报错但S7-1200用100ms轮询周期却时不时超时最后发现是变频器的通信任务优先级设计问题响应时间存在明显的最大抖动。要拿到可靠的轮询周期基准只能实测从站的极端响应时间不能拿调试软件的手感来替代。3. TCP半死连接Modbus TCP最深、最隐蔽的陷阱3.1 为什么Modbus TCP比Modbus RTU多出一个“连接维度”前面说的这些坑本质上都是“数据解读”和“参数配置”层面的问题哪怕全踩一遍也只要对照工具逐项排除就行。真正让我觉得Modbus TCP“藏得最深”的坑是TCP连接本身的状态失效问题。做Modbus RTU的时候一条485总线主站发请求从站回响应一个请求一个应答没有“连接”这个概念。从站掉电重启、总线干扰、拔线插线都不影响下一次请求重发。主站不关心对方什么时候在线只要发出请求后能等到响应就行。但Modbus TCP不同它把TCP协议作为承载层而TCP是一种面向连接的、有状态的传输协议。连接意味着通信双方在内核里维护了一套状态信息对方的IP、端口、序列号、确认号、发送窗口、接收缓冲等等。连接建立后你的每一次“发请求”实际上都是在一个既有连接上发送报文。问题是Modbus TCP的应用层完全没有定义任何形式的“心跳”或“保活”机制。请求来了就处理响应回完就继续等下一个请求。如果一端悄无声息地消失——比如设备断电另一端在短时间内根本感知不到。这才是所有“神秘故障”的根源。你可以把半死连接想象成打电话A和B正在通话B那边突然断线、把电话扔在桌上走了但A手里的线路还是“通话中”状态。A继续对着话筒说话B听不到B也不会回话A就这么对着一个死连接自言自语。Modbus TCP现场最经典的故障画面就是这种“电信级”的死连接。3.2 半死连接的现场全过程设备重启 → 请求黑洞 → 超时重传我复盘一下3号温控器那次故障的完整技术过程。3号温控器断电瞬间S7-1200与它之间的TCP连接在S7-1200这一端还保持着“已建立”状态。设备重启后温控器的TCP协议栈初始化它自己完全不记得这个旧连接也不会主动通知PLC“我重生了”。此时S7-1200继续通过旧连接发送Modbus请求这些请求到达温控器后温控器发现这是一个自己根本不知道的TCP连接于是按照TCP协议发送一个RST重置报文试图把这条连接打断。正常情况下这个RST会让S7-1200感知到“连接被重置”从而触发错误处理。但问题就在于现场网络环境不可能像实验室那么干净。交换机的缓存、防火墙策略、链路拥塞或者从站侧TCP栈的异常实现都可能导致RST报文没有及时送达甚至被丢弃。S7-1200不知道连接已死只能继续在旧连接上发送请求每一个请求都因为没有响应而触发TCP层的重传机制。TCP重传有一个自适应超时算法根据历史往返时间来估计重传间隔。如果之前通信一直很顺畅往返时间很短那么初始重传间隔会非常小但重传次数多了超时时间会按指数退避递增。表现到现场就是第一个请求在500ms的Modbus超时后报错第二个请求可能要等1秒第三个可能要等2秒越拖越长。你明明把Modbus请求超时设成了500ms但实际一个轮询周期下来可能已经在TCP重传层耗掉了几秒钟。更糟的是如果你的程序在Modbus超时后立即重试下一个请求又发到同一个死连接上TCP层可能还在等前面那个报文的重传确认新报文只能排在发送缓冲里。请求越积越多整个轮询就彻底冻结了。3.3 Wireshark里能看到但从不被留意的RST包那次现场抓到包后现象非常清晰。我用Wireshark挂在电脑上过滤器写的是tcp.port 502看到S7-1200反复向3号温控器发送Modbus请求报文但响应报文一个都没有。真正让我确定问题根源的是3号温控器断电重启后出现的几个RST报文。其实RST在很多Modbus TCP现场里都会出现但绝大多数人抓包时根本不会注意。一个RST报文看起来不像正常的Modbus事务Wireshark默认视图里会把它标成红色但它不携带任何应用层数据很容易被当作“底层杂音”忽略过去。可就是这个RST揭示了“旧连接已经失效”的全部真相。排查时还有第二个细节值得注意看TCP重传标志。Wireshark里如果出现大量的TCP Retransmission或者TCP Fast Retransmission而且这些报文都是同一个连接的那基本可以断定这条连接已经半死了。Modbus TCP的请求报文本身很小可能只有12个字节左右在Wireshark里一排排红色重传报文刷屏就是一个很直观的“半死连接”特征。我当时看到的现象是4台从站的Modbus请求全部发到各自独立的连接上3号温控器这条连接上全是重传和RST而另外3台从站的请求全都正常发出但得不到响应因为整个轮询循环已经被3号温控器卡死了——它不返回错误也不返回数据PLC逻辑永远在等它超时。3.4 S7-1200的MB_CLIENT为什么特别容易踩中“半死连接”S7-1200的MB_CLIENT指令有几个使用习惯会让“半死连接”的影响放大到整个轮询系统。第一个习惯是让CONNECT信号长期保持TRUE。MB_CLIENT在CONNECT为TRUE的情况下会建立并维持连接这是标准用法。但问题在于很多程序里CONNECT接的是一个常ON位从站重启后S7-1200不会主动尝试新建连接它只会在旧连接上继续发请求每次都超时、每次都失败而MB_CLIENT又不负责重连于是这个从站就被永久卡死。第二个习惯是REQ信号被固定成常TRUE或者上升沿处理不严谨。MB_CLIENT的要求是REQ有上升沿时才触发一次请求如果REQ一直被置位请求会一个接一个地往外发根本不等待前一个事务结束。这种写法在半死连接状态下尤其致命因为它会以极快的速度把一个已经失效的连接填满重传队列让TCP层更加混乱。第三个习惯是错误处理后没有“强制拆链”的步骤。很多人遇到MB_CLIENT的ERROR位为TRUE只是做一个故障标志清了之后重新触发REQ试图再读一次。但连接本身已经处于半死状态单纯的“重发请求”没有任何意义正确做法是先让CONNECT变FALSE等连接彻底断开再置TRUE重建连接。这三个习惯叠加在一起就构成了现场最典型的一个故障场景从站重启一次整个轮询系统跟着瘫痪直到PLC断电重启。4. 四台从站轮询的串行陷阱一个站故障拖死所有站4.1 串行轮询的时间预算不是每台100ms而是“超时叠加”用一台S7-1200轮询4台从站最直观的写法是写一个循环先查1号、再查2号、再查3号、最后查4号每一台等待完成或超时后再进下一台。这种写法节省了通信资源但也把所有的延时风险全部串在了一起。我来算一笔时间账。假设每台从站正常响应时间是100ms4台加起来是400ms一个轮询周期大概半秒听起来很不错。但你需要额外考虑每个从站的异常状态如果1号从站掉线你的Modbus请求要等多久才能拿到错误如果你设置了500ms请求超时那么1号从站就要白等500ms如果TCP半死连接还在重传实际等待时间可能翻倍。轮询周期的真实公式是轮询周期 各站正常响应时间之和 所有故障站的请求超时时间之和假设4台中有一台掉线且掉线站的请求超时是1000ms那么完整轮询周期就变成3×100ms 1000ms 1300ms比原来慢了一倍多。如果这台掉线站触发了TCP重传实际耗时可能从1000ms膨胀到3000ms以上整个系统的刷新率烂到无法接受。这还没算上PLC任务扫描周期的叠加效应。所以设计轮询时第一件事就是给每个从站设置“独立的事务超时”并且这个超时不能太长。500ms的请求超时对大多数从站都够用但一定要确认它真的在500ms时放弃当前请求而不是被TCP重传机制拖着走。4.2 TCP重传与事务ID冲突响应比请求晚到的后果四台轮询还有一个隐蔽的问题和Modbus TCP协议头里的“事务ID”有关。每个Modbus TCP请求报文都有一个事务ID用来把请求和响应配对。主站发一个事务ID为0x0001的请求从站响应时也会带着0x0001。正常通信时一应一答很好对应。但半死连接场景下情况会变得非常混乱。TCP层在旧连接上重传一个请求这个请求如果迟迟没有响应应用层可能已经超时并转为“重连”状态。重连成功后你又发了一个新请求事务ID可能是0x0002。这时候如果旧连接上的响应终于到达了——比如设备重新上电后终于把这个旧连接的残留报文处理了——响应带的事务ID是0x0001主站的协议栈如果还守着0x0002的事务ID这个0x0001的响应就会被当作无效帧丢弃。这种“迟到的响应”造成的偶发超时在四台从站轮询时尤其阴魂不散。因为它不是每次都出现而是只在“设备重启 旧连接重传 新连接建立”这个特定窗口里出现排查时极其难复现。4.3 现场事故复盘1号机断电2、3、4号机全部超时的真正原因回到那个项目现场把抓包数据捋一遍真相其实非常符合刚才的分析。3号温控器断电那会儿S7-1200的MB_CLIENT正轮询到3号。PLC发了一个读请求事务ID是0x0023没响应。TCP层开始重传Modbus层的请求超时500ms到了MB_CLIENT返回ERROR程序根据常规逻辑往下走到4号从站把请求发出去。但4号从站的响应其实很快就到了问题是4号的响应报文可能被3号“迟到的重传风暴”挤占或者说等到PLC轮询到4号时程序内部还在处理上一轮的异常状态没有及时转换到4号的事务ID上。更简单的解释是程序轮询到4号时发现4号的数据也没刷新因为前一轮3号超时没有完成程序通过一个共同的状态位让整个轮询序列都停住了。我以前很不理解为什么一个从站故障能拖死整条轮询链直到亲手调过这种“串行依赖”逻辑后才明白问题往往不是PLC真的收不到其他从站的数据而是程序把“前一站超时”当成了“整个轮询序列失败”的充分条件无条件中断了后续请求。这种设计在Modbus RTU时代影响不大因为RTU主站的重试机制很简短但在Modbus TCP的半死连接面前一次超时很容易膨胀成长期瘫痪。5. 根源解决给Modbus TCP轮询补上真正的重连机制5.1 用状态机管理连接连接检测、断点重建、请求串行认清半死连接的机制后解决方案其实已经摆在眼前不要“信任”TCP连接把“连接检查”和“断线重连”当作Modbus TCP应用的一部分。我现在的标准做法是把每个从站的轮询流程拆成几步用程序里的状态来表示第一步检查连接是否建立。如果连接没建立置CONNECT为TRUE等待连接成功再发请求。第二步连接建立后触发请求等待响应或等待超时。第三步如果请求超时不直接重复触发请求而是先把连接断开置CONNECT为FALSE等待一个断开确认周期再重新置TRUE。第四步连接重建后再从第一步开始。这个流程的关键点是“断开重建”必须比“重发请求”优先。很多程序为什么会反复超时因为它在半死连接上不断重试重试一万次也没用重试次数的增加只是在加剧TCP层的重传堆积。有些工程师觉得每次超时后断开重连太繁琐会让通信变慢。其实不然。对于正常的从站一年都难得出现一次超时对于真正掉线的从站你断掉旧连接、重新建立新连接最多耗时几十毫秒到几百毫秒远远小于你在半死连接上空转几十秒的代价。5.2 用S7-1200实现4台轮询的方案选型单MB_CLIENT与每台独立MB_CLIENT具体到S7-1200轮询4台从站通常有两种架构各有适用场景。第一种是单MB_CLIENT顺序轮询。一个MB_CLIENT实例程序里轮流把4台从站的IP、端口填到ADR参数中。这种方案的优点是占用的程序空间少、通信带宽好控制但缺点是每切换一个从站都需要先断开旧连接、再建立新连接。因为MB_CLIENT在连接建立后修改ADR参数并不安全通常必须把CONNECT拉低再拉高等待连接状态稳定后再发请求。连接断开和重建需要时间所以4台轮流下来会有一半左右的时间耗在连接切换上。第二种是每台从站一个MB_CLIENT实例。程序里建4个MB_CLIENT块每个块固定对应一台从站的IP和端口大家各自独立维护连接。这种方案的优点是连接不切换轮询速度快程序逻辑更直观缺点是每个从站都会保持一个长期连接的TCP资源如果你的从站设备TCP栈很简陋比如只允许一个客户端连接那另一个调试软件一旦连上它PLC这边就会被踢掉线。对“4台Modbus TCP轮询”这个典型需求如果从站设备本身没有“单连接”限制我更推荐每台独立MB_CLIENT。4个连接并不多S7-1200完全扛得住而且把每个从站的轮询隔离成独立状态机一个从站掉线不会拖死其他从站。如果从站设备明确限制连接数只有1个那就只能接受单MB_CLIENT轮询但需要把连接切换逻辑写正确先记录当前从站索引。对当前从站发请求等待超时或响应。完成之后将CONNECT置为FALSE等待一个扫描周期或一个50ms定时器。切换索引修改ADR参数将CONNECT置为TRUE等待“连接已建立”。再触发REQ请求。这个过程中最忌讳的就是在CONNECT保持TRUE的情况下直接改ADR去连下一台很多“轮询第二轮就断线”的故障就是这么来的。5.3 把断电重启纳入出厂测试轮询程序的验收标准还有一个我后来越来越坚持的验收标准每一套写好的Modbus TCP轮询程序都必须通过一轮“暴力测试”。测试方法很简单在现场投运之前把每一台从站依次断电重启观察PLC这套轮询系统能否在短时间内自动恢复。具体标准是单台从站断电10秒后重启系统最多在30秒内恢复对该从站的数据读取。单台从站长期断电另外几台从站的轮询周期不能明显劣化。全部从站断电后同时恢复系统能在1分钟内自动恢复到稳定轮询状态。这套测试能非常有效地暴露“半死连接”相关的各类Bug。很多时候开发阶段用Modbus Poll调试一切正常因为Modbus Poll会在连接断开后自动重连过程完全透明掩盖了TCP层的问题。而PLC程序里如果不做断线重建一测必翻车。我自己吃过的亏就是当年没做这个测试到现场才踩进深坑。现在不管是西门子、三菱还是其他支持Modbus TCP的PLC只要是我手写的轮询逻辑这套暴力测试都是必过项。6. 事后总结我后来是怎么避免再踩这个坑的6.1 三条我用得最多的经验第一条经验永远不要假设TCP连接是“可靠长连接”。Modbus TCP的承载层是TCP但TCP连接本身不保证永远有效。设备重启、网络拔插、交换机级联切换都可能让连接变得半死。你的轮询程序必须默认“连接随时会断”才能写出真正能自愈的逻辑。第二条经验让步Modbus TCP轮询程序的错误处理机制里把“断线重建”当作一个独立、显式的环节而不是把重发请求当成万能解法。重发请求只适合“丢包”场景不适合“连接失效”场景。连接失效时唯一的自愈路径就是断开、重连、再发请求。第三条经验把轮询系统的故障隔离做好。一台从站的故障不能影响其他从站。在程序设计时给每个从站分配一个独立的状态记录区一台超时了只标记这一台故障下一轮还是按时去轮询其他从站只是故障站的重试频率可以适当降低。不要因为某台从站连着超时几次就把整个轮询循环停下来。6.2 诊断工具箱抓包、连接数、停机测试最后分享几个排查工具大家遇到类似问题可以直接照做。抓包是最直接的手段。Wireshark过滤器用tcp.port 502重点关注三类报文RST报文、TCP重传报文、ACK异常。如果看到某个连接上不停有重传却没有任何Modbus响应那基本可以锁定半死连接。连接数检查也值得做。很多低端从站设备只允许建立1到2个TCP连接PLC占了一个连接调试软件再连一个第三个连接就会被拒绝。有些“轮询偶尔超时然后自己恢复”的奇怪问题其实是上位机软件不定期抢占连接导致的。遇到这种从站记住一条原则调试时用完Modbus Poll就断开别一直挂着。停机测试就是5.3说的暴力测试这里再强调一遍。每台从站都要做“运行中断电重启”试验而且要在轮询系统稳定运行一段时间后做不是刚上电通信成功就完事。因为半死连接的问题往往在运行一段时间后才暴露刚上电时所有连接都是新建的看不出问题。做这个测试时我会在PLC程序里记录每个从站“连续超时次数”和“最近一次重连时间”恢复后从数据里就能清楚看到从站重启后多久被重新纳入轮询周期。这个数据也是给甲方验收时最有说服力的交付物。我也补充一点经验Modbus TCP这个协议并非不成熟恰恰因为太简单很多工程师从一开始就只盯着“发送请求、接收响应”这个应用视角忽略了TCP连接状态的管理才是真正决定系统可用性的部分。把这个视角补齐Modbus TCP其实可以做得非常稳定。我在后来的几个项目里都按这套重连机制做从站断电重启再也没成为过系统级故障。