干了十几年车间自动化，以前是玩单机设备，就是那种“PLC+触摸屏+变频器”的老三样，日子轻松愉快。直到这几年被推着做软硬件系统集成，才发现水有多深。你以为把设备连上网就完事了？数据采集上来只是第一步，后面还有数不清的坑。今天聊聊我踩过的雷，如果你正打算上MES或者数据采集项目，这篇可能给你省下几晚上加班。
协议夹生饭：为什么看起来能连却总掉线
先说说最基础的通信。车间里设备五花八门，老的有RS232，新的有Profinet，中间还夹杂着一堆自定义协议。我用过一个老式注塑机，厂商只给了一个串口协议，文档没写清楚，回传数据的高位字节和PLC对不上，结果压力值实时刷新时跳得跟抽风一样。查到最后才发现，对方用的是高字节在前，我按低字节在前解析了。
所以选型阶段就得多留个心眼。现在主流都用OPC UA，统一建模，跨平台，确实香。但有时候设备太旧，只能走Modbus RTU。这种时候别纠结，加个协议转换网关就行。但网关这东西也有坑，我碰到过某个网关的Modbus寄存器映射和PLC里定义的不一致，导致温度区数据读出来翻了十倍。真是离谱。
通信参数也马虎不得。波特率、数据位、停止位、校验位，看起来基础，但现场电工师傅帮你接个线，可能就把跳线帽拨错了。我们调试一条线，光是一台设备就折腾了两天，最后发现是RTU和ASCII模式没对应上。这种低级错误，真的会让人怀疑人生。
数据流从哪来，到哪去：架构设计的一些教训
通信打通了，下一个问题是架构。数据从设备出来，是直接上云，还是先落到边缘？我之前做过一个项目，为了省事，所有数据都直接推送云平台，结果车间网络一波动，数据全堵了，现场看板直接白屏。后来改成边缘网关缓冲，先存在本地，再定时上传，这才稳当。
边缘计算的好处不用多说，关键是该放多少计算下去。举个例子，有些数据需要在毫秒级响应的，比如安全门联锁，那就必须走硬线或者PLC本地逻辑，千万别指望云。而一些OEE统计、设备利用率，放到边缘算好再传，省带宽还快。
还要考虑上下层系统的边界。MES要的是工单、产量、不良品率，ERP要的是物料和成本，你要是把这些一股脑全塞给PLC，那PLC就疯了。我见过一个项目，把订单排程直接写到PLC里，结果一换产品就得重新烧程序，真正跑起来就苦了。
所以画数据流图的时候，就得把每一层该干什么理清楚。这不光是技术活，更是沟通活。设备厂商、IT部门、生产部门，各方都有自己的一套词汇，我有时候觉得系统集成一半时间在做人肉翻译。
那些调试到凌晨三点的坑
说几个印象深刻的坑。第一个是字节序，刚才提过，但值得再强调。不同品牌PLC的WORD结构可能不一样，西门子走大端，三菱走小端，你要是混着用，数据全乱。我们在整合一条产线时，有台检测设备的坐标值左右翻转，搞了半天发现是字节序问题。这种问题不光是数据错，还可能让设备动作走偏，出安全事故。所以集成时要统一字节序标准。
第二个坑是IP地址冲突。听起来很基础对吧？但车间改造常有新增设备，IT部门把网段规划得乱七八糟，有时候设备一开，就把网关给顶掉了。我们那次排查，用wireshark抓包，发现一堆ARP广播，差点没晕过去。
第三个坑，也是我最头疼的，就是数据时间戳。不同设备时间不同步，导致MES计算节拍时忽快忽慢。后来通过NTP对时，才勉强正常。但NTP也依赖网络，网络一抖，照样歪。
对了，还有PLC里的数据类型。PLC里的INT和REAL，转换起来超级烦。有一个配方数据，从触摸屏传上来，PLC直接当INT处理，结果小数全被截掉，产品重量恒定偏小。这类问题，你从数据上看很难发现。
说到底，软硬件系统集成不是堆设备，而是让设备之间能有默契地配合。这需要工程经验，更需要耐心。
如果你现在正做车间集成，我给你的建议很简单：先把协议调研清楚，别急着接数据；架构上分层，该边缘就边缘，该云端就云端；调试时备好抓包工具，多一点耐心。毕竟，数据在车间里迷路，最后损失的是交付时间。祝你好运，少踩些坑。
