兄弟们，最近是不是也被PLC和MES断连这事儿搞得头疼？上一秒还在正常采集数据，下一秒就“断线重连”，生产看板直接飘红，领导在边上催，你盯着报错日志干瞪眼。别急，这活儿我干了好几年，今天就跟大伙儿唠唠这些坑和怎么填。
先说个真实案例
去年我一个兄弟在汽配厂，上线才三个月的产线，MES老是报“PLC连接超时”。他们IT团队折腾了一个礼拜，换了交换机、升级了网线，还怀疑是MES服务的问题，结果最后发现是PLC的通讯任务里写了个循环延时，每次循环跑数据包时卡了800毫秒，正好和MES的采集周期冲突。改了个参数，世界清静了。
你看，很多时候不是设备坏了，也不是系统炸了，就是一些不起眼的细节在搞鬼。
第一步：先分“谁先掉线”
断连这事儿，不能上来就骂MES或者怪PLC。先做一件最简单的事：看日志的时间戳。如果是PLC主动报错“连接关闭”，那多半是PLC侧在闹情绪；如果是MES报“超时未收到响应”，那可能是MES吃数据消化不良。
怎么理解？就像两个人打电话——PLC是那个说话慢吞吞的老师傅，MES是急性子的小年轻。老师傅一句话还没说完，小年轻等不及就挂了，这算谁的？大多数断连是MES侧超时设置太短，或者PLC侧数据包太大导致响应慢。
第二步：排查网络“三件套”
别一上来就怼着防火墙ACL调半天，先看三个最基础的：
- 丢包率：用ping -t持续测试，连续半小时，丢包超过0.1%就要查网线接头、交换机端口协商。记住，工业以太网里哪怕0.01%的丢包，在频繁读写场景下都会累积成断连。
- 网络拥堵：车间里摄像头、扫码枪、AGV小车都在走同一张网，MES和PLC抢带宽就像早高峰抢车道。最简单的办法：给PLC单独划个VLAN，或者限一下其他设备的流量。
- 双工模式：很多老PLC的网口默认是半双工，而新交换机是全双工自动协商。一旦协商失败变成半双工对全双工，就会疯狂碰撞丢包。强制把交换机端口设为100M全双工，很多疑难杂症就消失了。
第三步：看看PLC的“体力”够不够
PLC这玩意儿老实，让它干什么它就干什么。但你要是给它的通讯任务太重，它就会“手忙脚乱”。比如：
- 同时有多个客户端（MES、SCADA、HMI）轮询同一个PLC，每个都要求500ms刷新一次，PLC的通讯处理器就爆了。
- 一次读取上千个寄存器，数据包太大，拆包重组时出错。
优化方法：把一个大读请求拆成几个小包，每包不超过200个字节；或者把实时性要求高的数据（比如设备状态）和一般数据（比如产量统计）分开，用不同的通讯周期。就像食堂打饭，高峰期先让打一个菜的人走，别让打八个菜的人排在前面堵着。
第四步：MES端的“消化能力”
MES服务器如果配置过低，或者程序里用了阻塞式的SQL查询，那MES读取PLC数据时就会卡住，等数据库查完才去收下一个包，这时候PLC以为连接断了就主动断开。
排查方法：在MES服务器上开个资源监视器，看看读PLC的那几个线程的CPU等待时间。如果发现大量“Wait”状态，八成是内部处理太慢。解决方案：把数据采集线程独立出来，用内存队列先缓冲，再由另外的线程写入数据库。别让慢IO拖死实时通讯。
第五步：协议配置里的“坑”
现在主流用OPC UA或Modbus TCP。OPC UA虽然强大，但证书验证、安全策略配置不对，也会导致频繁断连。Modbus TCP简单，但很多PLC的Modbus TCP实现有坑——比如连接不关闭、响应超时默认太短。
血的教训：有一回客户用西门子S7-1200走Modbus TCP，MES每2秒发一次读请求。结果发现PLC内部Modbus库在处理异常报文时会自动断开TCP连接，然后MES侧等5秒重连，这3秒的间隙就造成了数据缺失。解决方案：在MES侧加一个重连机制，并在PLC侧把“允许保持连接”参数设为TRUE。
最后，给个稳的操作流程
你要是新到一个车间排查断连，按这个顺序来：
- 从MES日志里找出最近一次断连的时间点。
- 去PLC看这个时间点前后的CPU负载、通讯错误计数。
- 用Wireshark抓包，重点看这段时间有没有RST包或者重传。
- 如果是固定周期断连，大概率是MES的采集任务卡死；如果是随机断连，先查网络物理层。
- 最后，不管查没查到，一定要测试：让MES连续跑24小时不停歇读PLC，别再用“断连后自动重连”来掩盖问题。
兄弟，智能制造这事儿，底层通讯就是产线的“神经”。一次断连可能就让几百个零件报废，所以别怕麻烦，慢慢排查。如果实在搞不定，或者想看看别人家是怎么处理的，可以去 itfangan.com 翻翻具体案例，那上面有不少实战文档，比看理论书管用多了。今儿先聊到这儿，改天有空再说说数据采集后的脏数据清洗——那又是一个大坑。