上周四下午，实验室那台六轴机械臂又停在那不动了。学生小李凑在屏幕前调了半天网关，说配置没问题啊。我低头看了一眼电柜——抓手气缸的到位信号压根没接进中间继电器。他愣住了：“这不应该是软件的事吗？”
这句话我听过太多遍了。
他们脑子里，互联互通约等于加个网关
机械设计专业的学生一碰产线互联互通，第一反应往往是：买块通信模块，插上，配个 IP，收工。软件组网嘛，跟机构学、材料力学有什么关系？
关系大得很。真的。
我让他们拆过一条小型装配线——就四个工位，上料、拧紧、检测、下料。机械结构不复杂，三天能把三维搭出来。可一旦要求“互联互通”，问题立刻冒头：拧紧枪的扭矩数据从哪取？检测工位的 NG 品怎么反向通知上料机械手停送？每个动作的完成信号，是气缸磁开给出的，还是编码器脉冲？
全是机械侧的接口决策。
有个学生设计分拣线，电气图都画完了，输送带节拍定在 1.8 秒一件。他给 PLC 设了 50 毫秒的通信周期，结果数据滞后得离谱，分拣气缸追着物料跑，误动作一堆。后来他跟我说，老师，我原来以为通信周期越短越好。
不是的。机械节拍和通信周期得配着看。这个道理，纯讲理论课，讲十遍他也没感觉；让他跑一次线，立马就懂。
协议选型，其实是个教学取舍
说到具体协议，这里有个很现实的问题。产线互联互通用什么？Modbus TCP、Profinet、EtherCAT、OPC UA……名字一列，学生就晕。
我一开始特别想在课设里上 OPC UA。信息模型漂亮，语义化，往数字孪生那边一接就通，明摆着的方向。结果呢？学生配了两周，卡在地址空间建模上。机械专业的孩子，你让他理解节点、引用、类型定义，他脑子里全是问号，机械设计的手感全丢了。
后来我改了策略。基础组网先用 Modbus TCP，简单、直观，两小时能点亮一个往返通信。等他们把“机械动作—信号—数据—反馈”这条链打通了，再往上加 OPC UA 做信息层。
分层教学。先解决“通不通”，再解决“通得对不对”。
这个取舍我纠结了很久。纯从技术先进性讲，直接上 OPC UA 更“正确”。可对机械专业大三的学生来说，先建立物理层的映射直觉，比掌握一套高雅的信息模型重要得多。他们将来进现场，看到电柜里那排端子，得知道哪个信号对应哪个动作。
对吧？根基不在这，谈什么语义化。
一次翻车课设，改了我的讲法
去年有个学生的毕业设计，做多工位协同的装配线互联互通。机构设计干净，通信方案也写了满满几页。答辩前一周跑来跟我说，联调联不通。
我陪他查了一晚上。机械没问题，PLC 逻辑也对。问题出在一个不起眼的地方——两个工位之间用了不同厂家的光电传感器，一个 PNP 输出，一个 NPN 输出，接进同一块 IO 模块，电平逻辑反了。下游工位一直在等一个永远不会来的信号。
他整个人都懵了。因为这个错，跟他脑子里“互联互通”的概念完全不搭边。他以为这是协议的事、网关的事、代码的事。谁能想到，卡他的是一根线的极性。
说实话，那晚我也挺懊恼。这门课我之前一直把重心压在通信方案和软件上，机械侧的电气接口一致性讲得太轻，学生自然也跟着轻视。
后来我在课设任务书里加了一条硬性要求：所有传感器的类型、输出形式、供电，必须在机械设计阶段就列表对齐。不是画完机构再补电气，而是机构设计的同时把信号接口一起定下来。
这个改动看着小，效果挺明显。学生开始主动问：这个工位的气缸，信号是本地采集还是远程采集？采集点放柜内还是现场？线长会不会影响信号？
问题一多，说明他们真的进到产线互联互通的现场逻辑里了。
我更愿意把它当成一门接口课
现在再上这门课，讲法变了。
不先讲协议栈。先讲接口。
机械接口、电气接口、数据接口，三层摞起来看。每一个动作，从机械执行，到信号产生，到数据上传，再到指令下发，走的是哪条路？中间哪一段最容易断？
我让学生在纸上画一条产线的“信号漂流图”——从最末端的传感器，一直漂到 MES 界面。画完他们才发现，自己设计的机械结构，在整个信息流里只占一小块，偏偏就是这一小块，决定整条链能不能闭合。
有学生问我，老师，那我是不是得把通信也学深一点？
我说，不用深到去做协议开发，但你得知道数据从哪来、到哪去、中间经过了谁。这个把握住了，机械设计和产线互联互通才不是两张皮。
至于那些复杂的组态、网关、云平台……工具而已。工具会换。接口思维不会。
写到这，想到下周又要带新一轮课设。但愿这次，他们能早点意识到——那根看不见的线，其实一直连在机械侧。
