先说个古怪的现象。产线上每台单机都活着，各自精度都达标，可连成线之后，要么撞机，要么等着等着就停线。你查程序，查电气，查机械，最后发现谁都没错——但系统就是错。
干了十几年设备，我越来越觉得多机联动的难点不在单机，而在协同的粒度。你管得住同步，管不住抖动；管得住防撞，管不住节拍。今天这篇，不聊教科书上的理论，纯粹是工程现场那点事。
一、滞后从哪里冒出来的
很多工程师喜欢把联动问题归结为信号延迟。对，但也不全对。先看硬件。总线周期是第一个坎。你用PROFINET RT，周期做到1ms，感觉挺快——可两台设备之间还要加上PLC的扫描时间、IO刷新时间、伺服驱动器的滤波时间。一圈下来，打个折扣，实际响应可能到了4-5ms。
4ms什么概念？设备速度150mm/s时，位置偏差0.6mm。这对精密装配来说，就是废品。
更隐蔽的是机械传动间隙。联轴器弹性体、减速机回程间隙、同步带跳齿……这些非线性因素让理论上的同步指令到了末端就变成毛刺。你算得再精确，负载一变，全乱套。我见过一条包装线，两根分料螺旋轴的同步相位总是偏，折腾了三天，最后发现是其中一根轴的减速机螺栓松动。
所以呢？先分清滞后是确定性还是随机性的。确定性滞后可以用时基补偿，随机性只能靠冗余和处理。别一上来就上高精度方案，先拿示波器测信号时序，再拿激光对射器测实际位置，数据说了算。
二、硬同步与软同步——到底选哪个
软同步就是走总线，主站发周期指令，每个从站按各自定时器执行。便宜灵活，但同步性能取决于总线抖动。EtherCAT在这方面很强，分布式时钟能把各从站同步误差压到0.1微秒以内，前提是你得正确配置DC（Distributed Clock）。
硬同步则是用编码器反馈直接锁存，比如做飞剪或者电子凸轮，常用高速编码器信号同时触发各伺服驱动器的锁定输入。这种方式没有网络延迟，延迟只来自硬件电路本身——但代价是接线复杂，而且只能处理单一主轴。你要是需要多主轴联动，硬同步就有点吃力。
我的建议很俗：能用硬同步就硬同步，不能用再软同步。尤其设备之间距离超过10米，软同步的抖动会显著增加。别信销售吹的“亚微秒级同步”，那都是实验室数据。现场有变频器，有接触器，EMC不干净，抖动放大两三倍很正常。
举个例子，某锂电池涂布机，主动轴与从动轴用电子凸轮联动，一开始软同步，涂布边缘总是出现波浪纹。后来改成编码器硬同步，纹路消失。所以——有时候就得走老路。
三、互锁逻辑——安全门，还是鬼打墙？
多机协同里最烦人的不是同步，是互锁。谁先在先动？谁允许谁？谁必须等谁？
你按IEC 61131-3的SFC写流程，感觉逻辑很清晰。但实际设备一跑，传感器延时、气缸动作时间偏移，就可能出现两个工位同时申请同一资源。比如一条装配线，机械手在A工位放料，下一循环它要去B工位取料，结果A工位还没放完，B工位的夹具已经闭合——啪，撞了。
所以互锁必须做信号握手，不能只靠时序。具体说：每个工位完成动作后，输出一个“完成”信号，下一个工位必须检查这个信号为真，并且自己的“允许启动”信号也被上游确认，才能继续。听起来像是废话？可现场很多程序是单线顺序执行，以为时序对了就行，忽略了对异常状态的响应。
我踩过最大的坑是：互锁逻辑放在PLC的OB1里，扫描周期10ms，结果一个逻辑分支执行到一半，另一个设备已经发起请求——数据不一致。后来全部改成事件驱动，用高速工业以太网（比如PROFINET IRT）传输，PLC把互锁判断放在专用中断OB里，才把响应时间压到1ms以下。
对了，别忘记安全类互锁必须走安全继电器或安全PLC，常规PLC互锁只用于生产逻辑，不承担人身安全保护。这是ISO 13849-1的底线。
四、一个实际案例：双工位CNC上下料协同
前年帮一家汽配厂改造连杆加工线。六台CNC，两台机器手负责上下料，还有一条输送线。麻烦在于：两台机器手共用一条轨道，且加工节拍不一致，一个快一个慢。你要是按平均节拍调度，快的机器手会撞上慢的。
我们做的是动态优先级调度。
- 每台CNC加工完，发“请求上料”信号。
- 机器手控制系统根据自身当前位置和轨道上的占用信号，计算到达时间。
- 如果两个请求冲突，则判定哪台CNC剩余等待时间更长——优先服务加工余量短的，也就是避免大老板压货。
这里有个细节，轨道上有两个和机器手同步移动的“避让区”，用硬限位开关＋光电传感器双重检测。机器手只有在避让区空闲时才能进入另一台CNC的服务区。这部分逻辑我直接用CPLD写在硬件层，不经过PLC——因为PLC的扫描周期不够快，无法防止高速运动中碰撞。
结果呢？改造后单件节拍从95秒降到74秒，但最费劲的不是算法，是排查轨道上那些伪信号。机器手经过时光电传感器被振动触发，滤波时间调长后又漏检。最后在传感器支架加了橡胶垫外加屏蔽双绞线，才稳定。所以，纸上算得再好，现场振动、干扰、机械形变，全是你爹。
下图是当时画的时序逻辑示意，各位感受一下这复杂度：
再说说参数设定。伺服驱动的刚性响应——你设太大，机械振动加剧；设太小，同步误差大。我们是先空运行，用示波器看实际位置偏差，把比例增益调到临界阻尼状态，留15%的稳定余量。速度前馈也必须加，否则直角拐角的尖点跟你过不去。
五、节拍优化逻辑——别迷信最大速度
你有没有遇到过这种工程师？上来就把传送带速度调到最大，电机选型大一号，以为能压节拍。结果电流飙升，热量累积，减速机漏油，然后故障停机更频繁。
多机联动的节拍优化，本质是减少等待。比如上图里的机器手，从A点移动到B点，如果中间经过C点且C点没有必须停的逻辑，那就直接走圆弧插补，不要走“到点停，再启动”的梯形曲线。一个启停动作浪费800ms，一条生产线有十几个动作点，那就是十几秒——比你提速20%强多了。
我们常用加速度前瞻（Look-ahead）算法，让运动控制器提前规划路径，避免在尖点处急停。PLCopen的运动控制块里，MC_MoveDirectJog配合动态速度缩放参数，可以实现在线调速度而不打断运动。
但注意，前瞻算法的缓冲长度别设太大。我发现有人喜欢把缓冲设成10个点位，结果路径偏移严重，撞了夹具。经验值是缓冲长度不要超过规划路径总长度的5%，同时必须在执行前用轨迹仿真验证。
六、关于协同的小抄
做多了你会发现，多机联动协同管控的核心不是“控制”，是妥协。你妥协于机械间隙，妥协于总线抖动，妥协于传感器重复精度，甚至妥协于地面振动。工程师要做的是在妥协中找到一个平衡点，让整个系统的鲁棒性足够强。
具体到实际方案，我给几条铁律：
- 所有从站的时间基准必须统一。要么都用分布式时钟，要么都用硬件锁存，不要混用。
- 互锁信号必须带“回读确认”。发送方要知道接收方是否真的执行了，而不是发出去就完事。
- 节拍计算永远按最坏情况算。别用平均时间，因为一个气缸没到位就可能滚雪球。用蒙特卡洛模拟或者直接用历史数据算P95，稳得多。
- 调试现场要准备一个长网线和一台笔记本。很多上位机软件在特定设备上才能跑，这本身就像个玄学。
最后，别迷信进口设备。我见过某德国产线，逻辑上互相等待导致整线节拍衰减30%，因为厂商把安全距离设得太保守。后来我们用优化算法压缩了非安全方向上的等待时间，节拍直接升回去了。所以，协同管控既要有硬件基础，也得有软件策略。先理解物理，再玩逻辑。
写到这里，倒想起刚入行时师傅扔给我一句话：多机协同，一钟一表，各有其时。两个表走不准，你得先对时。现在想想，确实是这个理。
就聊这么些。如果各位正在被多机联动的时序问题折磨，欢迎从这些点入手排查。有些坑，跳过比爬出来舒服得多。
