很多做工业自动化的中级工程师，一碰到不同设备的协议对接就头疼。花大价钱买了网关，插上线通了，一跑生产就出问题。本文把近十年做项目攒下来的经验、踩过的大坑整理出来，都是能直接拿去用的落地经验。
为什么你做的工业协议适配总是现场翻车
去年给南方一个主机厂改焊装线，老线上面四台ABB IRC5机器人，原来走的Profibus-DP，新上的3D视觉焊缝检测系统是国内一家厂商做的，只支持EtherNet/IP。当时为了省成本，找了个不到三千块的通用网关，想着不就是转个码吗，能有啥问题。
插上电，地址能扫到，数据能读，一切正常。一开量产，不对了。机器人等待视觉检测结果的时间，比预期多了200ms。整条线节拍从12秒一台降到12.6秒，一天少出近百台车身，甲方现场负责人直接把我们堵在会议室不让走。
问题出在哪？很多人刚做适配的时候都有这个误区：觉得协议适配就是物理层通了、能读能写就完事了。完全不管不同协议的实时性要求、应用层语义匹配。
这个案例里，通用网关只做了传输层的转发，根本没处理EtherNet/IP的优先级标记，数据包在网线里排队，自然延迟飘得厉害。说白了，就是拿拉货车跑赛道，能不慢吗。
谁踩谁知道。
工业协议适配的核心选型权衡
说实话，现在做协议适配的方案真多，从几块钱的开源协议栈，到几十万的专用转换模块，选哪个完全看场景，没有绝对的好坏。
我一般分三类场景选：第一类，普通数据采集，比如给MES读设备的电流、温度、产量，响应要求几十ms就够，点数也不多，选通用第三方网关就行，性价比拉满。第二类，逻辑控制类，IO点数几百个以内，响应要求1-10ms，选带协议栈固化的硬件网关就够，只要认准支持对应协议的实时等级就行。第三类，运动控制、同步协同，要求周期抖动小于1ms，那千万别图便宜。
之前在一条锂电池极片轧制线上，试过用软适配跑在Windows工控机上，省了小十万的专用模块钱。看起来一切都好，结果Windows自动更新，把网卡的优先级给改了，定时任务被系统抢占，丢包率直接跳到3%，轧出来的极片厚度公差直接超差，一次废了两吨料，损失比省的钱多十倍都不止。
按照GB/T 30094-2013 工业以太网通信性能测试规范的要求，运动控制类应用的丢包率必须低于0.001%，周期抖动不能超过1ms。普通的软适配根本达不到这个要求，必须用带硬件加速的原生协议转换方案。
不过话说回来，这两年国产方案进步真的快，原来只有德国厂商能做的Profinet IRT适配，现在国内好几家都做出来了，价格只有进口的一半，性能还不差，真的挺惊喜。
现场调试必做的三个隐形检查项
调试的时候，很多人就是通了就交差，留下一堆隐患。我现在每次做适配，固定要做三个检查，少一个都不验收。
第一个，连续72小时稳定性测试，不能只测半小时一小时。我之前碰过一个项目，白天测啥问题没有，一到晚上，工厂里的大功率整流机组启动，电网电压掉了10%，网关的电源纹波超标，就开始频繁丢包，半夜生产线停了，我大冬天从被窝爬起来赶去现场，冻得打哆嗦，那种懊恼，现在还记得。从那之后，不管甲方催得多急，72小时测完再说。
第二个，检查字节序和数据映射对齐。你别笑，这个坑我踩过，也见过无数人踩。之前有个项目，压力传感器走Modbus RTU转Profinet，转出来的数值一直是对的好几倍，我们把传感器拆下来校了三次，换了两个新传感器，最后才发现，是网关里面把大端小端搞反了，高低字节错位，白瞎了整整两天功夫。现在我调试第一步，先写个小脚本把每个寄存器的数值挨个打出来对比，没错再往下走。
第三个，带宽冗余一定要留够。很多人算带宽，就是把所有要传的数据加起来，刚好卡着总线的最大带宽选。实际工业现场有大量的广播诊断包、设备轮询包，一跑起来就堵。我自己的经验，实际占用带宽不要超过总线总带宽的30%，剩下的都留给突发数据，绝对稳。
工业协议适配，从来不是什么玄乎的技术。说白了就是细节堆出来的，你对现场的干扰考虑得越多，对不同协议的特性摸得越透，出问题的概率就越小。
多踩几个坑，下次就顺了。
