示教器白键自定义：实现KUKA机器人一键触发复杂工艺-平芜编程栈

1. 我在车间里专门研究这个键的原因

1.1 每天重复的“翻屏操作”到底浪费了多少时间

做机器人调试和集成这些年，我最烦的一件事不是机器人报警，而是在示教器上反复去翻那些藏在层层菜单里的程序入口。拿一个典型的上料工作站来说，每天班前点检，操作工要做的动作无非是这几件：把机器人回原点、确认一下当前用的夹爪有没有装好、手动跑一遍空行程。听起来不难，但实操起来每一步都要在 smartPAD 上戳好几下屏幕：主菜单进去、选程序文件夹、翻页找到对应程序、点启动，弄完一个再退出来找下一个。一天两次换班，一次十来分钟，看着不起眼，一个月下来浪费在以“找入口”而不是“干活”上的时间，少说也有三四个小时。

更麻烦的是，这种操作极度依赖人的记忆力。今天换了新员工，他可能根本不知道那三个程序藏在哪个目录里；就算找得到，也可能漏掉其中一个步骤，最后导致机器人带错工具去抓料，轻则报警，重则撞夹具。我把这个问题跟同行聊过，大家的反应几乎一致：程序逻辑本身早就写好了，真正拖后腿的是“启动这些程序的入口太分散”。

1.2 白键：示教器上被绝大多数人无视的一排硬件

后来我在实验室里无意中注意到 smartPAD 正面的那一排白色按键。很多工程师天天拿着示教器，除了急停、运行键、模式开关、3D 鼠标之外，几乎不会主动去碰这些白键。我也一样，一开始以为它们只是屏幕软键的物理备份，或者是留给系统自己用的，从来没想过它能干什么。

真正让我改观的是一次翻操作手册。手册里提到 smartPAD 上有部分按键是“可自由配置”的，也就是说，操作者可以把某个功能、某个变量、甚至某个程序调用绑定到一个具体的物理键上。那一刻我才反应过来，这一排白键不是摆设，它是一排“没用起来”的快捷键。我后来在几个不同版本的 KSS 系统上都试过，不同资料里对它的叫法不完全一样，有叫用户自定义键的，有叫功能键的，本质上都是同一件事：通过配置，把一个物理按键变成一条可执行指令的触发入口。

1.3 我当时给自己定的目标

弄明白这件事之后，我给自己定的目标很具体：能不能把班前点检那三步动作，压缩成“按一个白键，机器人自动完成”？

当然，这里说的“解放双手”不是真的把手从示教器上拿开，而是把脑子里记住的“先做哪个、再做哪个、去哪里找程序”这些人工记忆释放掉，让机器人自己按照预设流程跑完，操作工只需要在旁边盯着看、手放在确认开关上随时准备急停就够了。我当时给自己划了几条硬约束：

不额外增加任何硬件，不接 PLC，不做二次开发屏，就用机器人自己带的示教器和控制器；
流程可中断，任何时候急停都必须能插进来；
给操作工一个明确的状态反馈，让他知道机器人现在是在去原点的路上，还是已经进入对刀环节；
最好能自定义，今天想一键回零，明天想一键换工具，改起来别太麻烦。

这几条约束最后把我引向了“按键信号映射 + 提交解释器调度 + 主程序执行”这样一个三段式结构。下面详细说。

2. 先拆清楚白键的底细，再动手

2.1 smartPAD 上的白键长什么样

不同型号的 smartPAD 按键布局稍有差异，但大规律是一致的：屏幕周围或者键盘区旁边会有一排颜色偏白、尺寸和普通按键不同的功能键。它们不像数字键那样参与字符输入，也不像急停键那样承担安全功能，位置往往偏在侧面或者屏幕下沿，看起来“没什么用”。

拿最常见的 KRC4 时代 smartPAD 来说，正面布局大致是这样：最显眼的是急停按钮和模式选择开关，中间是 3D 鼠标，右手边是数字键和方向键，运行键、启动键分布在附近。白键的位置通常不会跟这些常用键抢地方，所以容易被忽略。我之前在网上搜过很多次，发现大家都在搜“示教器 smartpad 正面”，说明很多人其实跟我一样，拿着示教器天天看，却记不清那些键到底哪个是哪个。

这里必须提醒一句：网络上任何关于“第几个白键对应第几个信号”的说法都只能当参考，不能直接抄。我见过有人把某个论坛上说的键号当成标准答案，结果在自己的 KSS 8.6 上怎么配都不对。原因很简单，KSS 版本不同、控制柜内 IO 配置不同、HMI 项目打包方式不同，白键最终映射到的变量位就可能完全不一样。所以，搞清楚自己现场这套系统的实际情况，比背任何键位表都重要。

2.2 白键信号进入控制器的三条路径

在我接触过的 KUKA 系统里，白键要从“物理按键”变成“程序能读到的信号”，通常有三条路：

第一条路是通过 HMI 配置直接映射成系统输入。也就是说，在示教器的配置菜单里，把某个白键绑定成一个逻辑输入信号，比如$IN[1]、$IN[2]。绑定完之后，按白键等价于这个输入点接通一瞬间。这条路最稳定，程序侧读取方式跟读普通传感器信号完全一样，跨版本兼容性相对最好，我建议优先搞懂这条。

第二条路是用 WorkVisual 做映射。KUKA 的 WorkVisual 不仅能用来装 Profinet 插件、配置现场总线通信，也能对 HMI 项目、按键分配做离线组态。很多工程师第一次打开 WorkVisual 是被“怎么安装 Profinet 插件”这种问题绊住的，其实一旦进了 WorkVisual，你会发现它的 IO 映射界面能把物理按键、总线输入、内部标志位都拉在同一个表里看，非常直观。但 WorkVisual 的问题在于版本匹配坑多，用不好反而越配越乱，新手不建议一上来就走这条路。

第三条路是在提交解释器里读系统变量。有些 KSS 版本下，按键状态可以直接通过系统变量在后台循环里轮询到，省去 IO 映射这一步。不过这个变量名和可用范围在不同版本之间差异比较大，有些版本甚至不开放公开读取，属于“能用全凭运气”。我的建议是，当它在特定场景下做备用方案，不要作为主线依赖。

2.3 在自己控制器上确认键号的具体方法

我每次到新项目现场，第一件事不是急着写工艺，而是先花二十分钟把白键和信号的对应关系确认清楚。方法也不复杂：

把示教器切到专家模式（或者工程师权限，取决于你们系统的用户组配置）。
进入配置/按键分配相关菜单，找到当前白键对应的目标信号。
手动按下一个白键，到输入状态监视界面看对应点位是否闪动。
把键号和信号号记下来，最好直接写在一张标签纸上贴在示教器背面。

更科学的做法是写一个极简的程序做“按键回声测试”：程序里放一段逻辑，检测到某个输入信号后，就把一个输出信号置位，同时在程序里记录当前键号。我实际测试的时候，会用两个不同白键分别映射到两个输入点，然后人为按其中一个，看程序走到哪个分支。整个流程本质上是把“按键物理动作”和“程序逻辑分支”之间用信号做了个一一对应验证。

这一步可能看起来啰嗦，但我踩过一次大坑：当时在新机器上直接按旧项目的键号表配好了所有白键，结果等到自动化测试才发现，我以为是$IN[1]的那个键，实际触发的是$IN[4]，幸好是在测试阶段，要是在量产线上按一下，把不该打开的夹爪打开了，后果不敢想。

3. 一键触发复杂工艺的整体设计

3.1 为什么只写一个 WAIT FOR 远远不够

很多人听到“白键触发程序”，第一反应是在主程序里写一句：

WAIT FOR $IN[1]

但实际这么写完会发现一堆问题。第一个问题是时序：如果你的主程序正在执行某段工艺，这时候按键信号来了，程序可能根本执行不到那句WAIT FOR，信号就这么丢了。第二个问题是并发：真实工作站里，机器人主程序可能正在等待夹具到位、等待气缸到位，多个条件同时卡着，一个按键信号根本无法解除所有阻塞。第三个问题最要命：如果主程序因为运行到结束语句已经回到初始状态，你按白键一次，它可能只会触发后面一条WAIT FOR的下一段逻辑，而不是“重新启动一个完整工艺”或者“切换一个工艺分支”。

所以我把白键触发的核心逻辑拆成了三个角色：按键只是负责发出“我想干什么”的请求，真正的调度交给一个一直在后台跑的决策程序，具体的动作则让主程序逐条执行。

3.2 提交解释器做主决策，主程序做执行

KUKA 的 KRC4 有一个提交解释器（Submit Interpreter）机制，简单理解就是：控制器里除了跑主程序的那个解释器之外，还有一个后台解释器，它可以在机器人主程序闲着、忙着、甚至停在某个中途状态的时候，一直在后台周期性循环。这个特性特别适合用来“盯”按键。

但提交解释器有个重要限制：它主要做逻辑运算和状态监控，不适合在里面直接执行运动指令。把PTP HOME直接写进提交解释器，轻则代码结构不合法，重则运行时跟主程序抢占运动资源，反而把机器人搞挂。正确的分工是：

提交解释器负责：轮询白键映射的输入信号，解析出“这是几号请求”，然后把它写到一个公共变量里。
主程序负责：在流程中的关键等待点，检查公共变量里的请求号，一旦发现新请求，就跳转到对应的工艺子程序去执行。

我用一个整数变量g_iRequest来传递命令。为什么用整数而不是多个布尔变量？因为如果同时按下两个白键，两个布尔变量会被同时置位，主程序不知道优先执行哪个；而用整数变量每次只存最新的一个请求号，天然带“覆盖”效果，谁后按谁生效，逻辑干净不说，排查问题的时候打印一个变量就能看出机器人上一次收到的是什么命令。

3.3 状态机设计与请求编号规划

为了让整个系统可维护，我给“一键触发”定义了这样几个运行状态：

IDLE：系统空闲，等待命令；
READY：工艺参数已就绪，可以启动；
RUNNING：正在执行某个工艺；
DONE：上一条命令执行完成；
ERROR：执行过程中碰到异常，需要人工介入。

表面上这是给机器人看的，本质上是给操作工看的。在示教器 HMI 上把当前状态做成一个显眼的文本显示出来，比让操作工盲猜“我按了键怎么没反应”要靠谱得多。

请求编号我个人习惯这样规划：

请求编号	含义	触发动作
0	无命令	不执行任何动作
1	回原点	调用回零子程序
2	换工具	调用换枪/换夹爪子程序
3	TCP 对刀	调用自动对刀子程序
4	空跑测试	调用空行程子程序
100	急停复位确认	清除错误状态
200	全部停止	触发程序内安全等待

这里的编号不是死的，你可以根据实际工艺扩充，但建议留出一段高位编号专门给“异常处理”和“维护模式”，避免将来新增正常工艺时把编号逻辑搞乱。

3.4 一次触发背后的安全边界

设计这套一键触发机制之前，我特意把“安全边界”单独理了一遍。最重要的一个现实约束是：在 T1/T2 手动模式下，机器人执行运动程序依然需要操作工按住确认开关，并且按启动键。白键顶多起到“选择流程并置入待执行状态”的作用，并不能绕过安全回路直接让电机转。这一点必须在前期就写进操作规范，否则操作工会误以为“我按了白键机器人没动，是不是坏了”。

另外，任何一键动作都应该能被急停随时打断。急停按钮的优先级永远高于一切程序逻辑，这是机器人控制器的底线，我的这套按键方案只是在这一底线之上做流程编排。最后，所有一键触发工艺，如果里面包含多步连续运动，强烈建议在正式投产前以最低速度、不带负载的情况下空跑几十个循环，确认每一步的轨迹和信号时序都没问题再提速。

4. 一个完整的可落地实例：一键完成“回零+换工具+对刀”

4.1 这个实例解决的是现场哪个痛点

我把设计落到一个真实场景里讲，大家更容易照着自己项目去套。假设现场有一个焊接工作站，机器人的任务是在两个工位之间轮流焊接。每天交接班的时候，操作工必须干三件事：

让机器人回原点，确保下一班开机的初始姿态是确定的；
去工具架上换一个当前生产要用的焊枪；
由于换了焊枪，重新执行一次 TCP 对刀，保证焊接轨迹一致。

按老流程，这三件事分别对应三个程序入口，操作工每天重复操作，偶尔还会漏掉“对刀”那一步。现在我要做的，就是把它压缩成一个白键可以搞定的活。

4.2 主程序框架：等待请求，分发任务

先把主程序的结构放出来。为了方便新手理解，我刻意把逻辑写得直白一些，工程上你们可以根据自己的变量规范加密。

DEF MAIN() ; 工艺请求号：0=空闲，1=回零，2=换工具，3=对刀 DECL INT g_iRequest g_iRequest = 0 ; 设定初始工具坐标系 $TOOL = TOOL_DATA[1] ; 设定基坐标系 $BASE = BASE_DATA[1] LOOP ; 等待后台提交程序下发请求 WAIT FOR g_iRequest > 0 ; 根据请求号分发到不同工艺 SWITCH g_iRequest CASE 1 GOHOME() CASE 2 CHANGETOOL() CASE 3 TOOLCHECK() CASE 100 ; 异常复位：清除状态标志，回到安全位 $OUT[1] = FALSE PTP HOME DEFAULT ; 未定义请求，直接忽略 ENDSWITCH ; 当前请求处理完成，清空请求号 g_iRequest = 0 ENDLOOP END

这段代码的核心思想是：主程序一直在一个大循环里等待g_iRequest变成非零值。后台收到白键触发后，会把这个变量改成对应的数字，主程序通过SWITCH跳转到对应子程序，执行完回到循环起点，等待下一条命令。

有个细节注意一下：在实际工程里，主程序一旦进入WAIT FOR等待状态，在示教器上看到的现象是“程序运行中，但停在某一行”，这非常正常。操作工不要误以为机器人卡死了，只需要看屏幕上显示的状态文本就知道系统在等什么。

4.3 提交解释器：轮询白键信号并防抖

接下来是核心中的核心：后台提交程序。它的任务是不断扫描白键映射的输入信号，一旦检测到某个键被按了一下，就设置对应的请求号。

DEF BUTTON_SUBMIT() ; 按键输入信号，按你自己控制器上的实际映射修改 DECL BOOL bKey1 DECL BOOL bKey2 DECL BOOL bKey3 DECL BOOL bKey1Prev DECL BOOL bKey2Prev DECL BOOL bKey3Prev bKey1 = FALSE bKey2 = FALSE bKey3 = FALSE bKey1Prev = FALSE bKey2Prev = FALSE bKey3Prev = FALSE LOOP ; 读取白键映射的系统输入 bKey1 = $IN[1] bKey2 = $IN[2] bKey3 = $IN[3] ; 上升沿检测：只有按键从0变为1的瞬间才触发一次 IF bKey1 AND NOT bKey1Prev THEN g_iRequest = 1 ENDIF IF bKey2 AND NOT bKey2Prev THEN g_iRequest = 2 ENDIF IF bKey3 AND NOT bKey3Prev THEN g_iRequest = 3 ENDIF ; 保存本次状态，供下一周期比较 bKey1Prev = bKey1 bKey2Prev = bKey2 bKey3Prev = bKey3 ENDLOOP END

这里最关键的代码就是“上升沿检测”那几行。如果不做这一步，按键按住不放时，$IN[1]就会一直为 TRUE，提交解释器每一轮循环都会把g_iRequest重新赋值成 1，主程序可能刚执行完一次回零，还没来得及把请求号清零，又被赋值成 1，导致同一段工艺反复执行好几遍。加上bKey1Prev这个“上一周期状态”后，只有按键按下瞬间（从 0 变 1）才会执行赋值，按住了反而不会再触发。

4.4 三个子程序：回零、换工具、对刀

回零子程序是最简单的，本质就是让六个轴回到一个固定姿态。这里我直接用轴角写死回零姿态，比起调用PTP HOME更直观，也能避免不同系统上HOME点被修改过的问题：

DEF GOHOME() ; 低速回零，避免交接班时机器人离原点位置太远产生大范围快速运动 $VEL.CP = 0.3 PTP {A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0} END

换工具子程序稍微复杂一点，因为换工具通常要跟外部抓手气缸做信号配合。我这里的思路是：先移动到换枪安全位，然后松开当前工具，切换工具坐标系，再移动到取新工具位，夹紧新工具：

DEF CHANGETOOL() ; 移动到换枪位 PTP {X 1200, Y 0, Z 800, A 0, B 0, C 0} ; 松开当前工具，输出信号给气动抓手 $OUT[2] = FALSE WAIT FOR NOT $IN[5] ; 等抓手松开到位反馈 ; 工具坐标系切回空手状态 $TOOL = TOOL_DATA[1] ; 移动到新工具存放位 PTP {X 1500, Y 0, Z 800, A 0, B 0, C 0} ; 夹紧新工具 $OUT[2] = TRUE WAIT FOR $IN[5] ; 等抓手夹紧反馈 ; 切换到新工具坐标 $TOOL = TOOL_DATA[2] END

注意这里$OUT[2]和$IN[5]只是示例参数，不同工作站的抓手控制信号、气缸到位传感器点位完全不同，你们要按现场 IO 表替换。我真正想让大家看懂的不是点位，而是“换工具”的本质：物理动作和工具坐标系切换必须同步完成，而且要做到位确认。最怕的就是抓手还没完全松开，机器人就已经开始移动，那一下可能直接把焊枪甩出去。

对刀子程序我写一个相对通用的版本：机器人移动到固定顶尖或基准球上方，然后以慢速执行一个找正动作，把当前实际位置记录下来，再调用系统或者自写的 TCP 校正函数更新工具坐标。具体公式因测量方案而异，这里给一个示意性框架：

DEF TOOLCHECK() ; 移动到对刀参考点附近 PTP {X 900, Y 300, Z 700, A 0, B 45, C 0} ; 慢速逼近参考点 LIN REL {Z -50} ; 记录当前位置作为 TCP 校准输入 ; 实际项目中这里会调用专业的校准程序包，或者自己写坐标变换公式 ; 校准完成后把结果写入 TOOL_DATA[2] END

很多用户会觉得“我用的焊枪厂商给了校准程序，不需要自己写”，这当然没问题。一键方案的重点不是把校准算法硬编码进去，而是把对方程序的启动入口接进我们的TOOLCHECK子程序里，让它被白键统一调度。你完全可以在这个子程序里直接调用厂商的校准程序，或者给 PLC 发一个启动校准的请求信号，等校准完成信号回来再继续。

4.5 部署调试时需要注意的执行顺序

这个实例跑通之前，我建议在控制器上按以下顺序调试：

先不映射白键，直接在变量监视窗口手动把g_iRequest改成 1、2、3，确认主程序的三个分支都能正常执行且能回到等待循环。
再映射第一个白键到$IN[1]，手动按一次，确认g_iRequest变成 1。
把另外两个白键也映射好，测试互不干扰。
最后做整链路验收：按一次白键，观察机器人是否只执行了对应工艺；执行完再按，是否还能再次触发。

我实测下来，这套方案把原来的班前点检从五六分钟压到了二十秒左右，而且操作工基本不用看程序列表，只需要记住“交接班按最左边那个白键”这一句话就行。唯一要接受的不便是，T1 模式下仍然要按住确认开关才能让运动执行，但这本来就是安全底线，没必要为了“解放双手”去绕过它。

5. 白键用到深处才会踩到的一些坑

5.1 按键抖动导致工艺重复触发

第一版方案刚上线时，我遇到过一种诡异现象：操作工只按了一次白键，机器人却把整套换工具流程连续跑了两遍。排查链路走下来，问题不是出在主程序，而是出在按键信号本身上。

原因有两层。第一层是物理抖动：机械按键在按下和松开的瞬间，触点会有一小段不稳定区间，反映到输入信号上就是短时间内出现多个上升沿。第二层是提交解释器循环周期很短，如果没有防抖处理，一次按键可能被误判成多次按键。解决方案就是我前面代码里写的“边沿检测 + 上一周期记忆”，但这只能解决“持续按住”的重复触发，解决不了触点抖动的毛刺。

要处理毛刺，可以在提交解释器里加一个简单的软件计数防抖：检测到$IN[1]变 TRUE 后，不要急着置位请求号，而是连续检测几个周期，如果信号稳定为 TRUE 超过比如 50 毫秒，才认为是一次有效按键。我当时用的是更笨的办法——在WAIT FOR条件里加延时分支，后来发现计数防抖更可控：

IF bKey1 AND (iDebounceCnt1 < 5) THEN iDebounceCnt1 = iDebounceCnt1 + 1 IF iDebounceCnt1 == 5 THEN g_iRequest = 1 ENDIF ELSE iDebounceCnt1 = 0 ENDIF

这个思路就是把瞬间的抖动窗口过滤掉，只有信号稳定一段时间后才认账。

5.2 在提交解释器里试图直接跑运动指令

这个坑在我刚开始设计的时候差点踩进去。当时想着让后台程序更“全能”，直接在提交解释器里写了一段PTP HOME，结果机器人控制器的反应很直接：要么编译阶段就报指令不受支持，要么运行阶段跟主程序抢运动资源，甚至出现轨迹被两个解释器争用、速度忽快忽慢的怪问题。

KRC4 的提交解释器本质上是为逻辑、信号、状态监控服务的，不是给运动规划用的。所有涉及轴运动、轨迹规划的指令必须由主解释器执行。我在前文强调“提交解释器只做决策，不做执行”，就是因为这个原因。如果你们项目里确实需要“一键动作里包含复杂运动”，正确做法是把它拆成一个独立子程序，然后让主程序在某个安全等待点收到请求后去调用它。

5.3 手动模式下按了白键但机器人不动

现场最容易收到的抱怨就是“我按了白键，机器人没反应”。大多数情况下不是程序逻辑问题，而是模式开关和确认开关的问题。KUKA 机器人在 T1/T2 手动模式下，即使程序已经运行到等待请求的状态，机器人也不会因为你按了一个白键就开始运动，你依然需要按住示教器背面的确认开关，同时按启动键，控制器才允许电机通电执行下一段程序。

有人会觉得这样很啰嗦，但我其实挺认可这个设计。白键方案再方便，也不能取代安全确认机制。为了让操作工不产生焦虑，我在 HMI 上额外加了一句状态提示：“请求已接收，请按住确认开关并启动”。这句提示看起来很简单，实际对车间新员工特别友好。

5.4 多个白键并排，误触比你想的容易

白键数量一多，按键又紧挨着，误触的概率真不低。我遇到过最夸张的一次，操作工本来想按“回零”，手指偏了一点按到了“换工具”键，机器人当场就去抓夹爪了。虽然没出事故，但把我吓出一身冷汗。

从那以后我强制自己做两件事。第一，在白键上方贴彩色标签纸，不同工艺用不同颜色区分，并且标签上写清楚当前绑定的工艺名称。第二，对高风险动作增加长按确认：要求操作工按住白键持续两秒才触发请求，这样即使手指不小心掠过键面，也不会触发工艺。长按确认的逻辑可以放在提交解释器里，核心代码是：

IF bKey2 THEN iHoldCnt = iHoldCnt + 1 IF iHoldCnt >= 40 THEN g_iRequest = 2 bKey2Exec = TRUE ENDIF ELSE iHoldCnt = 0 bKey2Exec = FALSE ENDIF

iHoldCnt累加到 40 大约对应两秒（取决于提交解释器循环周期，40 是示意值，你们要实测校准）。这个功能我后来把它做成了可配置的，回零这种低风险动作可以不要求长按，换枪、启动大范围运动这种高风险动作强制长按。

5.5 KSS 版本升级后按键映射失效

最后提醒一个隐藏得比较深的坑：系统升级。我有一台控制器本来跑 KSS 8.3，白键映射配得好好的，后来因为某个功能需求升级到 KSS 8.6，结果发现原来映射到白键上的输入信号全部失效，重新进配置菜单，里面的按键分配界面跟以前完全不一样。

排查下来原因很简单：系统升级后 HMI 项目被重建，原来存在旧配置文件里的按键映射表没有跟着迁移过去。这件事给我留下的教训是：升级前一定要把原来的按键映射关系、IO 映射表、WorkVisual 项目文件完整备份；升级后第一时间按我的“2.3 自检方法”重新验证一遍键号，而不是等产线开机了才发现。如果你们公司有不止一套机器人工作站，最好还做一个统一的“按键定义表”文档，写清楚每台机器的 KSS 版本、白键映射点位、绑定的请求号，维护起来会省很多事。

5.6 请求号复用导致的工艺串扰

最后一个坑和程序架构有关。如果在g_iRequest还没有被主程序消费完成时，操作工又按了一次白键，新的请求号就会覆盖旧的请求号。这在某些场景下是优点，比如你发现刚才按错了，可以立刻按正确的键去覆盖；但在另一些场景下是隐患，比如“回零”刚执行到一半，你按了一下“换工具”，主程序可能在下一次循环开始时才读到新的请求号，导致回零流程被强行中断。

所以我后来给g_iRequest加了一个“忙碌禁止”逻辑：主程序一旦进入某个工艺分支，就把一个g_bBusy标志置 TRUE；提交解释器在给请求号赋值前会先检查这个标志，如果机器人正忙，新的请求先存到一个待处理缓冲区里，等当前工艺结束后再自动取出执行。这样既避免了串扰，也不至于把操作工按掉的命令无声无息地吞掉。

当然，这套“忙碌禁止”也不是万能的。如果机器人执行到一半停在某个WAIT条件上等外部信号，而这个外部信号永远不来，那缓冲区里的新请求也会一直卡着。所以在主程序每个子程序的关键节点上，我都加了对急停状态、外部停止信号的判断，一旦发现异常，优先退出工艺，恢复到等待命令状态。这算是给“一键触发”再上了一道保险。

最后再分享一个我个人的习惯：每次调完一套白键方案，我都会在示教器旁边贴一张按键说明卡，上面写清楚“1号键=回零，2号键=换工具，3号键=对刀”，一旦工艺调整了，标签随时更新。车间里最可怕的不是技术方案不够高级，而是方案升级了，人的操作习惯还停留在旧版本。白键这个功能本身不大，但它教会我一件事：把重复劳动交给逻辑，把确认判断留给人类，这才是示教器上那排白键真正值得被认真对待的原因。