拆锁工位怎么和产线「对上拍」：硬线 I/O、Modbus TCP 与 EtherCAT 的取舍

单机演示和产线落地之间，最大的差别往往不是拆得下来拆不下来，而是能不能和上下游对上拍。所谓对上拍，拆开看是三件事：信号握手（我什么时候可以动、动完了告诉你）、节拍同步（我的动作起点和整线节拍对齐）、数据上传（这一颗螺丝的扭力、结果、时间要能被上层看到）。这三件事的技术要求完全不同，混在一起谈，就会出现"用 EtherCAT 传一个按钮信号"或者"用 Modbus 轮询去控伺服轴"这类错配。

最基础也最可靠的是硬线 I/O。一个输出给上游"请求放行"，一个输入接"工件到位"，一个输出回"动作完成"，再加急停、安全门、气压低压报警这些安全相关信号。它的优点是确定性和抗干扰：信号是电平，不存在协议栈、不存在连接超时、不存在版本兼容，一个万用表就能排查。缺点是点数随功能线性增长——每加一个功能就多一对线，改一次方案就要重新压线、重新编号、重新验证。工位功能一旦稳定，硬线其实是最省心的方案。

Modbus TCP 是很多项目的默认选择，因为它几乎没有门槛：一根网线、一个 IP、一张寄存器表，PLC、机器人、上位机都能说。它的定位应该是"非实时数据通道"——配方下发、参数切换、状态与计数上报、报警文本传输。用在控制回路里会出问题，原因是它的时序不确定：轮询周期受网络负载和主站扫描影响，从站响应时间没有保证，一次丢包要靠超时重试，表现出来就是偶发的动作延迟或丢步。这些现象在实验室里几乎不出现，在满负荷的产线上才会露头，排查成本很高。

EtherCAT 与 Profinet IRT 是另一个量级。循环周期可以做到 100 微秒到 1 毫秒，带分布式时钟，从站的输出时刻由主站统一对齐，因此适合两类场景：一是多轴需要插补或严格同步（比如双轴同时下沉、旋转轴与直线轴联动），二是视觉需要在运动过程中被硬件触发（飞拍），触发时刻必须精确对应位置。它们的代价是主站授权、从站一致性、拓扑与布线规范，以及调试人员的能力门槛。这些成本在单站上不一定划算，在整线统一架构时反而更低，因为备件、诊断工具和人员技能可以共用。

选型可以用四个问题快速收口。第一，站内有几个轴需要插补或同步？只有一个轴在动，硬线加脉冲或简单总线就够；两个以上轴要联动，就该考虑实时总线。第二，视觉是静止拍照还是运动中触发？静止拍照用软触发没问题；飞拍必须要硬件触发与位置对齐。第三，换型频率有多高？一天换几次配方，就需要一条能快速下发参数的通道，Modbus TCP 或 OPC UA 比人工改 HMI 可靠得多。第四，上层要不要实时曲线？只看结果和统计，普通以太网足够；要看毫秒级扭力曲线，就得在控制器侧缓存再上传，而不是靠网络实时推。

节拍同步本身有三种常见做法，各有各的坑。第一种是整线统一心跳，所有工位跟着一个公共节拍信号动作，优点是节拍整齐、容易计算产能，缺点是一个工位慢了全线等它，而且心跳丢失时全线一起停。第二种是上游给"到位"信号后本站自计时，优点是解耦、单站故障不影响上游，缺点是本站的累计误差要靠传感器纠正，否则会慢慢漂。第三种是由线体 PLC 集中调度，本站作为从站听指令，优点是全局最优、便于做在制品管理，缺点是把控制逻辑集中了，PLC 程序的改动会牵连所有工位。实际项目里最常见的是第二种和第三种混用：动作由本站自己排，放行与拦截由线体统一管。

握手信号的设计细节比协议选型更容易出事。最常见的错误是只用一个"完成"信号——本站置位表示拆完了，上游看到就放行。问题在于"完成"至少包含三种状态：正常完成、拆失败需要人工处理、本站故障停机。三种状态压在一个信号上，上游只能一视同仁地放行或者一律等待，结果就是不良品流下去或者整线卡死。稳妥的做法是 request / ack / busy / error 四线，加上超时判定：上游发出放行请求后在规定时间内没收到 ack，就报警而不是继续等。另外，急停、安全门、光栅这些安全相关信号绝对不能挂在软总线上，必须走硬线安全回路或专用安全总线，这不是保守，是规范要求。

数据上传这条线建议与实时控制彻底分开。控制环里不要塞 HTTP 请求或数据库写入，一次网络抖动就可能让机构停在半路。可行结构是控制器本地缓存最近若干条记录，由一个独立的上报进程按批推到 MES 或数据库，断网时缓存、恢复后补传。协议上 OPC UA 适合结构化数据和带语义的地址空间，MQTT 适合高频小报文和弱网环境，两者都不该进入控制回路。这套分离设计在带视觉自动拆螺丝机的工位上尤其重要，因为视觉结果的数据量比几个开关量高一个量级，混在控制通道里会把周期撑开。

回到工程实践，通信方案必须和治具、机架一样，被当成方案阶段的设计输入。它决定了电气柜里放什么、线槽怎么走、要不要加交换机和安全模块、上位机软件按什么架构写。等到设备做好了再谈"能不能接进我们产线"，通常的结果是加一个网关做协议转换，功能能通，但节拍对齐和诊断能力都打了折扣。给微小螺丝拆卸设备做产线集成时，比较省事的顺序是先拿到线体的节拍定义与握手时序图，再定本站的通信架构，而不是反过来。

最后是一个容易被忽略的判断标准：诊断能力。一条产线跑三年，通信方案的价值主要体现在出问题的时候能不能快速定位。硬线方案的优势是能用万用表逐点量；总线方案的优势是能看从站状态字、丢帧计数和拓扑诊断。选型时如果只比较"能不能通"，两种方案都合格；如果比较"坏了多久能修好"，答案会差很多。M0.8 到 M2.0 的工位通常布置得密、单站价值不算高，一旦停机影响的却是整段产线，所以M0.8-M2.0螺丝拆卸方案在标准化时把通信接口做成可选项而非固定项，正是为了让同一个机械平台能适配不同线体的架构要求。