车间那台老冲床开口说话：一段企业技术故事的脏活与真账
去年秋天，我在南京一家做精密钣金的厂里蹲了三天。目的不高级：把一台1998年的冲床接进系统里。老板原话是，别跟我讲大屏，我就想知道它今天到底停了几回、停在哪一步。听着简单吧？真干起来，头一晚我就被一根RS-485线教做人。
那台冲床没有网口。控制柜里一块老PLC，编程口还在，协议是串口那一套。车间里变频器一开，示波器上的波形跟麻花一样。线槽里还塞着行车电缆。你说直接插网关？能亮灯，但数据十分钟丢八回。这不是段子，是很多企业技术故事的开头：设备太老，现场太吵，需求方只想要一个数。
老旧冲床控制柜RS485接线现场调试
先别急着上云，老设备的嘴还没张开
老设备不是不会说话，它说的是方言。RS-485可以理解成一条半双工的总线，几台设备挂在同一对双绞线上，轮流开口。谁先说话？靠地址。说什么？靠协议。Modbus RTU就是其中一种常见方言：地址、功能码、数据、CRC16校验，像点名、提问、回答、核对口音。
我们踩的坑很具体。原线只有两根，屏蔽层悬空，通讯地也没处理。白天看着没事，夜班一开大功率设备，CRC错误率飙上去。后来加了隔离型收发器，两端补终端电阻，屏蔽层单点接地，线槽里把通讯线和动力线分开走。别小看接地和终端电阻，它们不产生故事，只终结故事。话糙。现场就是这样。
协议层也没省心。PLC的寄存器表是纸质的，还是手写改过的。某个地址写着运行状态，实际读出来是故障字；某个计数寄存器会翻转，65535之后回零。你直接把它当累计产量，月底报表能吓死人。我们做了三件事：按位解析状态字，把计数变化做成增量，再用边缘网关缓存五分钟。先保证数据不丢，再谈数据治理。
边缘网关干的活，说白了是翻译加记账。它轮询PLC，打时间戳，本地存一份，网络断了就排队，恢复后补发。上云走MQTT，主题按车间、设备、点位分层。新一点的设备可以走OPC UA，老设备就老老实实Modbus RTU转MQTT。技术不玄，难在把现场脾气摸清。
工厂边缘网关Modbus转MQTT数据采集调试
数据上来了，坑才刚开始
数据上来了，坑才刚开始
初版看板出来，老板看了两分钟，问了一句：这台机为什么每天停机三百次？我心里咯噔一下。不是设备疯了，是我们把信号抖动了。继电器触点抖动、工人点动、上下料碰一下，都被记成一次停机。后来加了状态机：连续运行超过五秒才算开机，停止超过十秒才记停机，故障字置位才进故障态。没有业务规则的数据，只是电压变化。
时间也是个暗坑。网关本地时钟跑偏，PLC没有NTP，云端按接收时间打点，班组交接班一算，产量对不上。我们改成网关定时校时，采集时打设备侧事件时间，再保留接收时间。两个时间戳，一个用于追溯，一个用于排障。听着啰嗦？出问题时就靠这啰嗦救命。
还有计数。冲床的行程次数不等于良品数。模具换型、空打、试模，都会计数。我们后来把计数信号和模具编号、工单号绑在一起，换型时强制复位。不是技术多高级，是得承认：企业技术故事里，一半是协议，一半是生产流程。你只懂协议，现场会教你做人；你只懂流程，数据又采不上来。
说个反常识的观察。不是所有老设备都值得连。那台冲床值得，因为它卡着交付节拍。旁边一台老钻床，一个月开两次，你给它装网关、拉线、做看板，维护成本比停机损失还高。技术人容易上头，看到接口就想接。老板要的是账，不是接口数量。先算停机损失，再决定采不采。这话不好听，但省钱。
边界与误区：别把所有故事都讲成AI
边界与误区：别把所有故事都讲成AI
有供应商来推方案，开口就是预测性维护。我问，轴承温度采了吗？振动采了吗？历史故障标签有吗？对方说可以先上平台。行吧。没有标签的预测，跟算命差不多。企业技术故事可以朴素：先做可视、可追溯、可报警。设备到底停在哪，换型用了多久，故障码出现频率如何。这些跑顺了，再谈模型。
安全边界也得说。老PLC的编程口不是随便开的，写操作更要命。我们采集只读，物理上做隔离，网关放在生产网边界，不让它直接摸办公网。有人嫌麻烦，等一次误写把程序冲了，就知道麻烦和事故哪个贵。
回到那台冲床。三天后，它终于能在看板上留下一条像样的曲线。老板没夸我，只说了一句：原来夜班停得这么碎。我挺高兴。不是因为大屏好看，是因为一段企业技术故事终于落了地：老设备开口，数据能对账，人能拿它做决定。剩下的，慢慢磨。对吧？