我最早遇到 MC_ProgramSpeedMotor1() 这条调用是在一条汽车焊装线的转台工位。当时设备手册被翻得快烂了标准 KRL 指令表里始终找不到它的完整解释最后是老工程师一句话点醒我这不是你日常写的运动指令它是力控软件包里的电机速度编程接口而且必须在后台循环里伺候它。后来我在好几个项目里反复跟这条指令打交道发现大家对它的速度行为理解普遍偏浅。很多人以为给个速度值它就按这个值跑实际上从参数传入到电机实际转起来中间至少隔了三层控制逻辑。这篇文章就把这条指令的来龙去脉、调速链路和现场踩坑记录完整拆开讲给正在做 FCT 相关调试和伺服单元速度控制的朋友一个参考。1. 指令从哪里来先弄清楚 MC_ProgramSpeedMotor1 所处的运行环境1.1 它在标准 KRL 指令集里查不到别浪费时间很多同事第一次看到 MC_ProgramSpeedMotor1() 的报错时第一反应是打开 KUKA 的 KRL 编程手册搜索结果一无所获。这个现象非常正常。标准 KRL 里负责运动的是 PTP、LIN、CIRC 这类指令配合 $VEL_AXIS、$VEL_CP 这些系统变量实现速度控制但 MC_ProgramSpeedMotor1 并不在其中。这条指令来自 KUKA 的力控和相关工艺软件包最常见的载体是 KUKA.ForceTorqueControl也就是现场常说的 FCT 包。在 FCT 框架下系统允许你把某个轴、某个外部驱动单元从普通位置伺服模式临时切换成速度可控模式通过一个运动控制接口把目标速度交给电机。MC_ProgramSpeedMotor 后面的数字 1通常代表电机编号或轴编号具体几号取决于你工程里定义了几个可控电机。我在做过的一个打磨单元里就用它控制一个外部转台轴。夹具把工件夹紧后转台需要以一个相对稳定的表面线速度旋转让打磨头在工件表面做恒力进给。用传统 PTP 或 LIN 去写圆周运动当然也能转但一旦力控反馈需要实时微调转速标准运动指令根本做不到这时候 FCT 包提供的电机速度编程接口就派上了用场。所以如果你想在标准 KRL 手册里找答案方向就错了应该去找 FCT 软件包手册和力控功能的技术附录。1.2 Submit 解释器是它的主战场这条指令还有一个让新手困惑的地方它很少出现在主程序 .src 的运动指令段里反而大量出现在 Submit 解释器或者后台循环中。原因是 MC_ProgramSpeedMotor1 承担的是一种过程级控制它需要在一个周期内反复被调用、刷新而不是像 PTP 那样执行完一条指令就结束运动。Submit 解释器在 KRC4 系统里相当于一个独立于主程序的后台任务以固定周期和主程序并行运行。把 MC_ProgramSpeedMotor1 放在 Submit 里意味着每个控制周期系统都会重新读取参数并下发到伺服驱动这样一来力控 PLC 或者传感器给出的实时速度修正确实能及时反映到电机上。在主程序里调用不是完全不行但主程序一旦运行到等待指令、暂停或者切换运动语句这条指令的刷新就会中断速度行为会变得非常跳现场最容易表现出来的就是转台一顿一顿。我自己常用的做法是单独写一个 Submit 文件专门负责速度编程接口的后台刷新。里面只做三件事读取外部使能信号、判断当前是否处于速度控制模式、调用 MC_ProgramSpeedMotor1 并记录返回值。主程序只负责告诉后台现在需要运行哪种工艺具体的速度刷新完全交给 Submit 处理。这样职责清楚后续排查问题也方便。1.3 软件包版本和安全配置共同构成的前提条件不能假设所有 KRC4 系统天然支持 MC_ProgramSpeedMotor1 的调用。这个指令需要对应的软件包被正确安装并激活常见的就是 KUKA.ForceTorqueControl 相关版本。如果软件包缺失你在编辑器里手工敲出这条指令编译阶段就会报未知标识符。另外安全配置同样关键。FCT 功能允许程序在运行时修改轴速度这涉及机器人安全监控范围。我在某个项目里就遇到了第一次调用时报Stop override active的问题查了一圈才发现是安全 PLC 侧没有把速度控制模式对应的安全确认信号置位。系统设计上当 MC_ProgramSpeedMotor1 被激活并接管轴速度时安全控制器需要确认我知道这台设备现在正在以速度模式运行否则机器人控制器会认为自己失去对轴位置的控制能力直接触发停止级响应。所以在现场接线和调试前我建议先确认三件事软件包是否已经出现在 WorkVisual 的项目结构里FCT 或工艺包授权是否激活安全配置中的速度模式确认信号是否已经映射到实际输入。这三项缺一不可任何人告诉你软包装了就能用你都要留个心眼。2. 速度行为的三层调速设定值、Override 与 FCT 修正2.1 第一层指令参数里的目标速度单位与方向约定先看指令本身的参数。MC_ProgramSpeedMotor1 一般会接收几个核心参数电机编号、控制模式、目标速度、加减速斜坡相关参数。不同版本的软件包给出的接口签名不完全一样但核心逻辑一致告诉系统我要把几号电机切到速度模式目标速度是多少斜坡时间多长。最容易出问题的就是单位。有些版本里目标速度直接是百分比比如 50 就代表电机额定速度的百分之五十有些版本则用工程单位比如 mm/s 或 rpm。如果你从别的项目复制了一段现成代码没有核对单位就上电电机可能会以超预期速度旋转这非常危险。我处理过一个外部轴程序里写的速度值是 80实际电机转速直接拉满就是因为原项目单位是百分比而这个电机型号的额定转速更高换算逻辑完全不一样。方向约定也值得单独说。MC_ProgramSpeedMotor1 的速度参数通常有正负号含义正负号决定电机旋转方向。有些工程师喜欢统一传正值再用额外参数控制方向有些版本则直接通过符号控制。无论哪种我强烈建议在程序开头做一次方向验证手动输入一个很低的验证速度比如额定速度的百分之三确认转向和工艺要求一致后再进入自动流程。方向反了在转台和打磨轴这类场景里不只是工艺问题还可能导致工件飞出或者工装损坏。2.2 第二层全局 Override 和轴组 Override 的叠加很多人忽略了一点即使 MC_ProgramSpeedMotor1 传入了一个明确的目标速度实际作用到电机的速度仍然会受到系统 Override 的影响。KRC4 里的 Override 不单单作用于主程序中的 PTP 和 LIN它同样作用于速度编程接口下发的速度设定值只是表现方式略微不同。全局 Override也就是示教器上的那个速度百分数会作为第一层缩放因子叠加到目标速度上。假设你传了 100 mm/s示教器 Override 在 50%那么基础输出就是 50 mm/s。如果此时用户把 Override 推到 120%这在 KRC4 里允许基础输出会变成 120 mm/s。这个叠加逻辑在调试阶段既方便又危险方便的是可以快速验证电机在低速下是否正常危险的是速度行为不再由程序唯一决定。轴组 Override 也要注意。KUKA 的轴组里往往有独立的倍率设定比如 $OV_JOG 和 $OV_PRO 这类变量会按轴组或者运动类型区分。MC_ProgramSpeedMotor1 控制的对象如果是某个外部轴或伺服电机它受的 Override 影响可能和控制六轴机器人的 Override 不是同一个变量。我在调试时吃过一次亏程序里和示教器都设成 100%但轴还是慢吞吞的最后发现是 WorkVisual 配置里那个轴组的速度倍率被限制成了 30%而这部分界面在调试初期根本没人去动。所以速度不对时别只盯着指令参数三级倍率都得查一遍程序内部倍率、轴组倍率、全局 Override。2.3 第三层力控回路对速度的实时干预这是 MC_ProgramSpeedMotor1 和普通速度赋值最大的区别所在。FCT 包引入的不仅是速度可设定更重要的是力或者扭矩可以作为反馈量实时修正速度。这一层修正通常发生在控制周期内部由 FCT 的控制算法根据传感器信号计算得出。用一个具体场景说明打磨轴的恒定进给速度。工艺上要求打磨头接触工件后接触力保持在 30N 左右。当打磨头遇到工件表面凸起时接触力会瞬时增大如果速度不变力可能冲到 60N造成砂带磨损或表面过切。引入 FCT 后控制器检测到力上升会在毫秒级时间内把速度编程接口的输出值向下调整让接触力回落到目标区间。这个调整不是改你程序里的参数值而是在内部叠加一个修正量所以你在程序里看到的 SpeedValue 可能一直是 30但实际电机速度已经根据力变化在 15 到 30 之间动态浮动。这层逻辑对现场调试非常重要。很多工程师看到 Trace 里力值波动正常但实际转速和程序设定不一致就误以为指令有问题。其实这正是 FCT 的工作方式速度是手段力是目标速度行为必须放在力控闭环里理解不能只看单点设定值。如果希望速度完全恒定那就不要启用力反馈的比例调节把 FCT 控制模式切成纯速度模式或者把力修正系数设为零。否则你会永远在程序写的速度和实际看到的转速之间找不到对应关系。3. 我常用的调用框架启停逻辑与参数组合3.1 用 SpeedControl 建立开关控制而不是裸调指令实际项目里我不建议直接在每个周期无脑调用 MC_ProgramSpeedMotor1那样会让速度控制的启停完全失控。我会建立一个开关式的控制块最外面是一个速度控制总使能内部再区分目标速度来源和异常复位逻辑。下面是我在实际项目中用过的一种框架具体接口名以你所装软件包版本为准但思路可以平移; Submit 解释器内循环 ; 外部 PLC 通过数字量输入给出速度控制使能 IF ($IN[101] TRUE) THEN ; 第一次进入时完成模式切换 IF (bSpeedModeActive FALSE) THEN SpeedControl ON bSpeedModeActive TRUE ENDIF ; 每周期刷新目标速度与斜坡 MC_ProgramSpeedMotor1( MotorNo : 1, Mode : #FCT_SPEED, SpeedVelocity : nTargetSpeedMM, Ramp : nSpeedRamp, ReturnCode : nRet ) ; 记录返回值便于后续诊断 nRetCodeBuffer nRet ELSE ; 退出速度模式时先退出再清标志 IF (bSpeedModeActive TRUE) THEN SpeedControl OFF bSpeedModeActive FALSE ENDIF ENDIF在这个结构里外部信号 101 是总开关第一次从 OFF 切到 ON 时才执行 SpeedControl ON避免每个周期重复执行切换动作。nTargetSpeedMM 和 nSpeedRamp 可以从主程序里的全局变量获得这样一来主程序可以随时修改速度目标后台循环负责执行。SpeedControl 这个开关指令在不同版本里名称可能不同有些版本直接叫 CTRL AXIS有些版本用 FCT_ACTIVATE 之类的功能块但本质都是建立进入速度控制模式和退出速度控制模式的边界。这个边界必须清晰否则后续的异常处理会非常被动。3.2 实际测试过的一组参数与斜坡设定参数设定上我以一套外部转台轴为例电机额定转速 3000 rpm工艺要求转台表面线速度约 500 mm/min转台直径 400mm。换算下来目标转速约 23.9 rpm对应额定速度的 0.8% 左右。这个例子很极端只是为了说明工程单位换算的必要性。实际调用时我更倾向于直接用相对于额定速度的百分比作为目标速度因为 FCT 内部和驱动通信时工程单位换算往往要依赖轴配置里的减速比和机械参数。如果机械参数没有标定准确你写 500 mm/min 人家执行出来可能是完全不同的速度。百分比模式绕开了减速比误差至少驱动层面的执行是准确的机械层面的误差再通过实际测试校准。斜坡时间我一般先设定 500ms 到 1000ms。这个参数决定了速度从 0 升到目标速度的时间。太短了容易造成机械冲击尤其是转台带着大惯量工件的时候太长则会让工艺启动段变得迟钝。我曾经为了照顾一个重型夹具把斜坡调到 2500ms结果每次启动都会在工艺传感器触发前还在爬速导致检测时序错乱。后来改成 800ms同时增加启动前的速度到达确认位才解决了时序问题。3.3 触发条件、退出时间与异常复位调用框架里还需要加入触发条件判断。速度控制不是一开启就要立刻全速运转必须等工艺条件满足。我常用的触发链是总使能 ON - 工件夹紧信号 OK - 安全门确认 - 速度模式使能 - 目标速度从零开始递增。每个环节都有对应的数字量信号或者内部标志。退出时间同样重要。当外部信号撤掉时速度模式不能马上让电机自由滑行而是要让速度斜坡降到零再退出速度控制模式。这个先降速、再断使能的顺序在气动夹紧和伺服电机配合的场景里属于保命级别的要求。试想一下转台带着 50kg 的工件在高速旋转你直接断开速度控制机械上会怎样。所以我通常在总使能 OFF 后先把目标速度置为零等电机监测到实际速度低于阈值或者一个固定延时结束才真正执行 SpeedControl OFF。异常复位方面我会监控 MC_ProgramSpeedMotor1 的返回值。当返回值出现非零错误码时后台循环自动把目标速度清零同时向 PLC 发送一个速度控制异常信号。复位流程是 PLC 先撤掉总使能现场确认无误后再重新给出 ON。这个设计看起来简单但在实际产线上能省掉大量反复重启控制器的时间。4. 那些速度不对的现场故障完整排查链路4.1 现象一信号给了但轴不动没报错也没报警这个现象最迷惑人因为系统没有任何报警程序也在正常循环调用 MC_ProgramSpeedMotor1但轴就是纹丝不动。我排查这类问题有一套固定链路从外到内逐层确认。第一步查使能链路上的所有输入信号。MC_ProgramSpeedMotor1 要真正驱动电机往往还叠加了一个驱动使能条件这个条件不一定是指令自身的参数而是来自安全电路或者伺服放大器使能信号。我就遇到过一次 PLC 程序升级后某个内部中间变量没有置位导致驱动使能一直处于 FALSE指令调用正常但输出被硬件锁住。第二步检查是否处于位置监控冲突状态。速度控制模式下如果机器人的位置监控或者轴位置偏差监控还在按位置模式运行控制器会在内部禁止轴运动。表现就是指令返回正常但实际速度始终为零。解决方式是在进入速度模式前将对应轴的监控模式切换成速度监控或者把偏差监控窗口放宽。第三步用系统变量确认当前有效速度是多少。通过示教器或者 Trace 查看实际轴速度如果实际速度变量里能看到一个非零值在变化但机械轴没动那就要怀疑机械传动本身了比如联轴器打滑、减速机卡死。我在一个老转台项目里就遇到联轴器键槽磨损程序里速度完全正常电机也转但输出轴就是不转这个和指令本身没有任何关系但如果不按链路排查很容易被带到沟里去。4.2 现象二Override 变化后速度掉零且无法自行恢复另一个高频问题发生在用户操作示教器改变 Override 之后。现象通常是工艺运行中操作工觉得转速太快把 Override 从 80% 降到 40%结果轴速度瞬间变成零而且怎么推 Override 都不恢复。这类问题的根因往往在速度斜坡和 Override 变化的交互上。当 Override 突降时系统会试图让当前实际速度快速匹配新的倍率这个匹配过程会触发一个向下的斜坡。如果此时 MC_ProgramSpeedMotor1 的目标速度被设定得比较低再加上 FCT 内部的低通滤波实际速度计算值会收敛到零附近。而恢复时由于速度编程接口需要重新建立速度设定窗口某些版本里必须先把速度模式退出再重新进入否则内部状态机锁在降速中。处理办法分两步。第一步是优化交互逻辑在后台循环里不要直接跟随 Override 瞬时变化而是对 Override 做滤波或者限制变化率让速度调节变得平滑。第二步是增加自动退出重入机制当检测到实际速度低于某个阈值且目标速度大于零时自动执行一次 SpeedControl OFF然后延时 100ms 再执行 SpeedControl ON强制刷新速度控制状态机。这个办法不算优雅但非常有效我在两个项目里都靠它避免了操作工频繁重启控制器。4.3 把变量、Trace 和系统状态串起来定位如果三层调速链路都检查完毕问题还没浮出水面那就需要借助 Trace 把所有关键变量记录下来一遍运行一遍分析。我推荐的 Trace 通道包括指令返回值、实际速度变量、目标速度变量、系统 Override 变量、FCT 力反馈值、当前运行模式标志位。举个实际例子。某个打磨项目中砂带机的电机速度周期性波动波动周期大约 4 秒。通过 Trace 观察发现FCT 的力反馈值也在以相同周期波动而力反馈波动的来源竟然是砂带接头处的一处硬点每个周期经过打磨接触区时都会造成力跳变。控制系统为了维持目标力自动把速度降了下来。从机械角度讲砂带接头是事故源从控制角度讲速度波动只是系统的正常响应。Trace 把变量的因果关系展示得非常清楚否则我们可能一直在调试速度参数反而把真正的问题搞复杂了。Trace 采样周期建议设在 4ms 到 8ms 之间太短占用系统资源太长捕捉不到力控调整的瞬态过程。至少采集整个工艺循环的前后 10 秒方便对比不同阶段的稳态和动态响应。5. 与传统 $VEL_AXIS 编程对比该选谁不该选谁5.1 直接写入 $VEL_AXIS 和走 FCT 指令的区别老一辈 KUKA 工程师在需要控制轴速度时可能会直接修改 $VEL_AXIS 系统变量。$VEL_AXIS 确实能影响后续运动指令的执行速度但它在本质上服务于位置运动也就是说它的作用是给位置插补提供速度上限而不是直接把轴切换到速度控制模式。MC_ProgramSpeedMotor1 走的是另一条路径。它把轴从位置闭环中部分解耦允许外部目标速度直接作用到驱动层同时保留必要的位置安全监控。相当于一个给速度的控制接口而不是给位置运动设定速度上限。用一句话概括$VEL_AXIS 适合在位置轨迹中调整运动快慢MC_ProgramSpeedMotor1 适合在需要持续长时间、允许速度围绕某个工艺目标动态调整的场景。如果你只是想让某个 PTP 运动慢一点完全没必要动用 FCT 这条链路直接用 Override 或者 $VEL_AXIS 就好。反过来如果你要的就是持续转动且速度可以随力实时变化那 $VEL_AXIS 做不到。5.2 与伺服焊枪、打磨、涂胶场景的配合关系我实际应用最多的是三类场景。第一类是伺服焊枪的电极修磨和预压紧动作。焊枪在修磨时电极帽需要以一个受控速度旋转或者进给速度太猛会把修磨刀片打坏速度太慢修磨效率低MC_ProgramSpeedMotor1 正好可以配合修磨工艺包按修磨循环参数驱动焊枪电机并且根据修磨时的阻力变化动态降速。第二类是打磨和抛光。这个在前面提到过核心优势是速度与力的协同。打磨深度、进给力、砂轮线速度三者互相耦合传统方案是固定速度调整压力但往往会出现压力波动大、表面质量不稳定。用 FCT 速度编程可以让压力保持恒定速度自动适应材料硬度和表面轮廓效果要稳定得多。第三类是涂胶和点胶。有些涂胶系统需要外部转台匀速旋转胶枪固定不动胶嘴相对工件表面的线速度必须保持恒定。如果转台用传统位置运动每圈的微小位置误差会造成线速度波动导致胶条粗细不均。速度编程接口可以让转台在圈与圈之间平滑调整转速补偿当前工件半径变化这是普通位置轨迹很难做到的。5.3 回到Speed behaviour这个标题要观察的到底是什么文章标题叫Speed behaviour MC_ProgramSpeedMotor1()那到底应该观察速度行为的哪些维度我总结下来是三个目标速度的跟随性、动态修正下的响应性、异常状态下的安全性。跟随性指的是实际速度与目标速度的一致程度。系统带宽足够、负载变化不大时实际速度应该长时间稳定在目标速度附近如果出现周期性偏差优先怀疑机械负载变化和 FCT 参数配置问题。响应性指的是当目标速度发生变化或者力反馈突变时速度多快能稳定到新状态。响应时间太长工艺调整会迟钝响应时间太短机械冲击又明显。响应性的核心调节参数是斜坡时间、力修正系数和速度滤波时间常数三者要搭配调整。安全性则是指速度控制链路在故障条件下能不能快速回到安全状态。包括驱动使能丢失时能不能立即停止力反馈超限时能不能自动降速安全信号断开时能不能进入保护性停止。我在每次项目验收时都会强行做一次运行中断开使能测试确认 MC_ProgramSpeedMotor1 控制的轴在异常断电时不会继续滑行这个测试必须通过才能交付。回到实际操作层面我个人有一个坚持了很久的习惯任何用到 MC_ProgramSpeedMotor1 的程序我都会在调试阶段做一张速度设定记录表表格里列出目标速度、实际速度、力反馈值、Override、电机电流这几项数据每隔一段时间记录一次。这样做不是形式主义而是因为速度行为这种问题靠感觉判断很不靠谱数据积累到一定量后很多似有似无的隐患都会浮现出来。比如某个速度值下电机电流持续偏高你就可以提前预判机械传动有问题而不是等到电机过载报警才处理。搞调试这行多留一组数据少熬一次夜。