ROBOGUIDE虚拟仿真：FANUC机器人示教编程抓放案例

简介：这份ROBOGUIDE虚拟仿真案例文件面向已具备FANUC机器人基础操作知识、希望用完整项目巩固示教编程与仿真流程的读者。案例基于ROBOGUIDE V9.4创建，围绕WeldPRO3工作站，可练习虚拟机器人系统搭建、外围设备模型添加、示教编程和仿真运行，弥补缺少完整练习场景的问题。压缩包为rar格式，共1个文件，以XML项目数据文件为主，包体约27.66MB，需预先安装ROBOGUIDE后打开；略高或略低版本通常可兼容，但建议优先使用与创建版本一致的软件。已有179人学习。读者可对照博主主页4篇基础教程，在完整工作站中熟悉模型布局、示教点设置与仿真验证思路；若软件版本与教程不同，机器人、工具和工装模型会有差异，但核心操作方法一致，便于迁移练习。

1. 从一台没有实体的机器人开始：把示教课搬进虚拟仿真

一个班里三十个人，实训室只有两台六轴机器人，轮一圈下来每人摸不到二十分钟，这是很多做机器人课程设计的人都会遇到的场面。ROBOGUIDE 配合 FANUC 机器人的虚拟仿真，解决的正是这个矛盾：不用排队等真机，示教编程的每一步都能在自己的电脑上完整走一遍，撞了也只是弹个提示。这套基础操作案例文件的价值在于，它给出的不是一个空工作单元，而是一个已经搭好机器人、装好夹爪、摆好料台、标定过工具坐标系、写好抓放程序的完整场景，打开就能从示教器界面一路点下去。对要交课程设计、要做毕业设计开题演示、要在没有设备的环境里讲清楚机器人编程流程的人，这比看十个小时视频有用得多。

2. 需求与技术选型：为什么把示教搬进虚拟环境

2.1 三类真实需求：试错、复现与可交付

第一类是试错成本。真机上撞一次，轻则换保险丝、重则修减速机，学生做完一个抓放循环手心全是汗，根本不敢改参数。虚拟环境里撞机的代价是零，可以放心地把速度从 250mm/sec 拉到 2000mm/sec 看它怎么飞出去，也可以故意把 CNT 值设成 100 看轨迹切角切到什么程度。这种"允许犯错"的环境，才是学会示教编程的前提。我见过太多人真机上一板一眼走完流程，出了教室就记不住 SHIFT 加坐标键是干什么的。

第二类是可复现。一份工作单元文件发给十个人，每个人打开看到的初始状态必须一模一样：机器人停在 HOME 点、夹爪是张开的、料台上摆着同样位置的工件、寄存器全部清零。真机做不到这一点，上一组做完没归位，下一组拿到的就是一个脏状态。案例文件把初始状态固化下来，谁打开都从同一个起点开始，出了问题也好对照——同一份输入跑出不同结果，那才是真正的玄学。

第三类是能交差的产物。课程设计也好、毕业设计也好，最终要交的不是"我做过"这句话，而是可展示、可检查的东西：一个能打开运行的工作单元、一份程序清单、一张点位坐标表、一段节拍记录。这些东西在虚拟环境里都能导出来，而且格式统一、便于放进报告。虚拟仿真真正的产出不是动画，是这套可核查的数据。

2.2 三种做法的对比：真机、离线仿真、只看视频

在决定用哪条路之前，先看清三条路各自的边界。真机示教的优势是手感真实，你能感觉到负载、能听到异响、能看到真实的定位误差；缺点是资源稀缺、碰撞代价高、状态不可复现。纯视频教学几乎没有门槛，但你看完永远不知道自己那一步对不对，因为没有任何反馈。离线仿真卡在中间：手感是假的，但逻辑、语法、坐标系、I/O 时序全是真的。

表格里"节拍数据参考性"这一行值得多说一句。仿真跑出来的节拍通常比真机乐观一点，因为它不建模线缆拖拽、不打滑、不计算真实的加减速爬坡。把它当相对值用没问题——改一个参数看节拍往哪个方向变、变多少，这个结论是可靠的；把它当绝对值写进报告说"本方案节拍 32 秒"，就容易被问住。我一般会在报告里写两组数：仿真节拍和估算真机节拍，后者在前者基础上留 15% 到 25% 的余量，并注明这是经验修正。

2.3 为什么虚拟控制器跑出来的程序能当真

这是很多人心里的疑问：软件里编的程序，拷到真机上能跑吗。ROBOGUIDE 的核心是一个虚拟控制器，它跑的是与实机同源的控制逻辑，所以你写的 TP 程序语法、寄存器编号规则、I/O 映射方式、坐标系切换逻辑，跟真控制器是一致的。换句话说，你在仿真里踩的语法坑，在真机上一样会踩；你在仿真里绕过去的坑，真机上也绕得过去。

这个特性决定了它的教学价值：错误是真实的错误，不是模拟器的怪癖。比如你在程序里忘了给用户坐标系赋值就调用 UF1，仿真会给你一个偏移得离谱的轨迹，真机也一样。再比如 CNT 值设得太大导致拐角切太多撞上夹具，这个现象在两边都会出现。反过来，只在仿真里成立的现象也有，主要是物理层面的：工件被抓起来之后不会真的掉落、线缆不会缠绕、电机不会过热。知道边界在哪，就不会把仿真结论无限外推。

2.4 硬件与版本的现实门槛

跑虚拟仿真不是零成本。工作单元越复杂，对显卡和内存的要求越高，一个带围栏、带输送线、带多个工件的场景，在中低配笔记本上转视角会明显卡顿。通常的做法是：学习阶段把场景砍到最小——一台机器人、一个工具、一个工件、一块地面，其余的等逻辑跑通了再加。加得越晚，调试越轻松。

版本匹配是另一个容易忽略的点。工作单元文件与虚拟控制器的版本之间有对应关系，用高版本软件打开低版本保存的单元，一般会提示升级，升级之后旧版本就打不开了。所以案例文件到手的第一件事，是复制一份副本再打开，原文件留着不动。这条规矩听起来小题大做，但真出过一次事后，我每次都是先复制再说。

3. 虚拟工作站总体设计：一个工作单元里装什么

3.1 工作单元骨架：机器人、工具、工件、周边

打开软件新建工作单元时，会先让你选工艺类型，搬运抓放选 HandlingPRO 这一支就够用。工作单元的骨架可以按四层来理解：最底层是场地，包括地面、围栏、安全门；第二层是设备，机器人本体、控制柜、可能的输送线或变位机；第三层是工艺要素，工具、夹具、料台、工件；第四层是逻辑要素，I/O 信号、寄存器、程序。四层分开建，后期改动才不会牵一发动全身。

机器人的选型不是随手挑一个。负载要覆盖工具加油件的总重并留余量，臂展要够到最远的点位并留出姿态余量，这两条不满足，后面的点位示教全是白费功夫。工具（夹爪）的建模重点是 TCP 位置——夹爪中心点在哪、Z 轴朝哪、X 轴指向哪，这三个量决定了后面所有点位能不能复用。工件则要考虑它是静态摆件还是会跟着机器人走，跟着走就要在仿真里建立抓取关系，否则机器人抬起来工件留在原地，看着特别别扭。

围栏和安全门在仿真里不是装饰。它们对应着实实在在的安全信号：安全门一开，机器人必须停。很多案例把这部分省了，结果学生到了真机上完全不知道安全回路怎么接。我的建议是哪怕场景再简单，也把安全门信号接上，让它参与一次仿真，亲眼看到门开机器人停，这个记忆比看图纸强。

3.2 虚拟控制器与示教器：把真机那套交互搬过来

工作单元建好之后要启动虚拟控制器，这一步相当于真机按下控制柜上电。控制器起来之后，示教器界面会以窗口形式出现，上面的按键布局、菜单层级、状态栏显示，跟实机示教器是同一套。别急着写程序，先花十分钟把几个基础操作摸熟：模式开关在 AUTO / T1 / T2 之间切换，T1 是低速手动，调试都用它；按住使能键（deadman）才允许运动，松开即停；SHIFT 加坐标系键循环切换 JOINT / WORLD / TOOL / USER。

坐标系的切换顺序值得专门练。JOINT 模式下每个轴单独动，适合从奇异点附近脱身；WORLD 模式沿世界坐标轴平移，适合粗定位；TOOL 模式沿工具自身的轴动，适合沿工件表面走；USER 模式沿用户坐标系动，适合整个工作站有倾斜或者旋转的场合。新手最常犯的错是在 JOINT 模式下试图"往上抬一点"，结果机器人绕了个大圈，吓得赶紧松手。这个坑仿真里踩一次，比讲十遍都管用。

状态栏那几个指示也要认得：当前工具号、当前用户坐标系号、当前速度倍率、有没有报警。程序跑飞了第一眼看的就是这里，很多时候问题就出在工具号忘了切——你以为在用一个尖嘴工具，实际还在用默认的零点工具，轨迹当然偏。这类问题在后面避坑那章还会展开。

3.3 案例文件的组织方式：把状态拆成可搬的模块

一份完整案例不该是一个大文件包打天下。工作单元本体、控制器备份、标定记录、文档四类东西的生命周期不一样：工作单元会不断改，备份是某一刻的快照，标定记录几乎不变，文档是给人看的。混在一起放，改一处就要重新打包全部。我习惯按下面的结构组织，好处是任何一个部分坏了都能单独替换。

案例包/ ├─ Workcell/ # 工作单元主体：机器人、夹爪、料台、工件、围栏 ├─ Backup_ASCII/ # 控制器 ASCII 备份，程序以 .LS 文本形式存在，可读可 diff ├─ Backup_Image/ # 控制器镜像备份，用于整机状态整体还原 ├─ Frame_Data/ # TCP 与用户坐标系的标定记录、点位坐标表 └─ Doc/ # I/O 分配表、程序说明、节拍记录、操作步骤

ASCII 备份和镜像备份的区别要说清楚：ASCII 备份出来的是文本，程序、寄存器、系统参数都在里面，能直接用文本编辑器看，也能放进版本管理里比对两次改动的差异；镜像备份是整机状态的完整快照，恢复之后连系统变量都回到那一刻，适合交付和归档，但不适合日常查看。做案例交付时两份都给，学的人想研究细节看 ASCII，想一键复原用镜像。

Frame_Data这一层最容易被忽略，但它才是案例能复用的关键。点位坐标脱离坐标系是没有意义的，P[3] 到底是哪，取决于它记录时用的是哪个工具、哪个用户坐标系。把标定数据和点位表一起存下来，别人拿到案例之后即使重做标定，也有个对照基准。Doc里的 I/O 分配表同理，DI[1] 是夹爪到位、DO[1] 是夹爪动作，这种约定不写下来，过两周自己都记不住。

4. 示教编程落地：从工具坐标系到可运行的 TP 程序

4.1 工具坐标系标定：三点法够用，六点法更稳

工具坐标系（TCP）标定的目的，是告诉控制器"你的手尖在哪"。没标定过的默认工具，TCP 在法兰盘中心，你按着 TOOL 模式往前推，实际是法兰盘在走，夹爪只是挂在那儿。标定之后，机器人转姿态时手尖不动，这才是能用来示教的工具。

三点法是最常用的：让手尖以三种不同姿态去碰同一个固定参考点，控制器据此解算出 TCP 的三维坐标。操作要点有三个——三个姿态的差异要足够大，最好一个竖直、一个倾斜四十五度、一个接近水平；三次触碰的参考点位置必须一致，点位误差会直接进到解算结果里；每次记录时机器人要停稳，别在微动的时候按记录。六点法在三点法基础上多记三个姿态，额外解算出工具的姿态，精度更高，适合夹爪有明显的方向性、必须保证 tool Z 轴垂直于工件表面的场合。

标定完了要做验证：切到 TOOL 模式，只转姿态不平移，盯着手尖看它是不是原地打转。如果手尖画圈，说明 TCP 有偏差，回去重标。这一步很多人跳过，结果后面所有点位都带着这个偏差，越走越偏，还以为是机器人精度问题。血泪经验是：标定花十分钟，返工花两小时，别省这十分钟。

4.2 用户坐标系与工件坐标系：让点位跟着工件走

用户坐标系（UF）解决的是另一类问题：工件本身是斜的、旋转的，或者同一套程序要用在多个摆放位置不同的料台上。做法是在工件表面对三个点——原点、X 方向上一点、XY 平面内一点——建立坐标系，之后所有点位都相对于它记录。

这样做的好处很直接：料台整体平移了二十厘米，不用改程序，重新标一次用户坐标系，所有点位自动跟着走。如果点位是相对 WORLD 记的，那就得一个个重教，教到怀疑人生。我一般会在案例里固定使用 UF1 对应主料台、UF2 对应输送线，程序开头显式写一句切换，谁看都明白。

有一个细节容易翻车：用户坐标系号在程序里是持续生效的，你在 A 程序里切到 UF2 跑完，回到 B 程序如果没显式切回 UF1，B 就还在 UF2 下执行。所以每个程序的头部都应该有一句坐标系设定，把它当成程序的前置条件写死，而不是依赖上一次运行留下的状态。这类"隐式状态"是仿真里最难查的一类问题。

4.3 运动指令与定位类型：J、L、C 与 FINE、CNT 的取舍

四种运动指令各有明确的适用面。J（关节运动）走的是各轴插补的最短路径，速度快、路径不可控，只适合在空间开阔的安全点之间转移；L（直线运动）保证 TCP 走直线，是接近、抓取、放置这些需要精确路径的场合的唯一选择；C（圆弧运动）需要三个点定义，适合沿圆弧边缘走；A（圆弧）用得少，一般用 C 就够。

定位类型 FINE 和 CNT 的区别，是新老手的分水岭。FINE 表示到位后完全停稳再执行下一条，位置准确但节拍慢；CNT 表示允许在距离目标点还有一段时就圆滑过渡到下一条，节拍快但会切角。CNT 后面的数字 0 到 100，数字越大切得越狠。抓取和放置点必须用 FINE，否则手没到位就开始动作，抓空或者撞件；中间过渡点用 CNT50 到 CNT100，能省不少节拍。

这个参数不是拍脑袋定的。判断方法是看轨迹：把 CNT 调大之后，在仿真里打开轨迹显示，看拐角处的实际路径离目标点有多远。如果切角切到工件里去了，说明这个位置的 CNT 值必须降下来。我给的经验值是，靠近工件的三个点以内一律 FINE 或 CNT0，离开工件三个点之后才允许放到 CNT50 以上。

4.4 一段完整的抓放程序与它的参数说明

下面是案例里的主程序，做的是从料台抓件放到输送线，循环执行。注意行首的标签、坐标系前置设定、以及每一条运动指令后面的注释，这些注释在真机示教器上也能看到，是给下一个接手的人留的活路。

1: ! MAIN_PICKPLACE —— 料台 A 抓取，放置到输送线 2: ! 前置：UFRAME_NUM=1，UTOOL_NUM=1，机器人处于 HOME 3: UFRAME_NUM=1 4: UTOOL_NUM=1 5: LBL[1] 6: J P[1] 100% FINE ; HOME 安全点，关节运动转移 7: L P[2] 800mm/sec CNT100 ; 料台正上方接近点，允许圆滑过渡 8: L P[3] 150mm/sec FINE ; 抓取点，必须精确定位 9: CALL GRIP_CLOSE ; 闭合夹爪并等待到位 10: L P[2] 400mm/sec CNT50 ; 先垂直抬升，脱离工件 11: J P[4] 80% CNT100 ; 转向输送线上方 12: L P[5] 150mm/sec FINE ; 放置点 13: CALL GRIP_OPEN 14: L P[4] 600mm/sec CNT100 15: JMP LBL[1] ; 循环

逐条说清楚。第 3、4 行是坐标系前置设定，显式把 UF1 和 TOOL1 激活，避免继承上一次运行的状态。第 6 行的 P[1] 是安全点，用 J 指令是因为这一段路径上没有障碍，走关节插补最快；速度 100% 指的是在手动速度倍率下的百分比，实际运行还要看倍率旋钮。第 7 行用 L 保证垂直下降的路径，CNT100 允许它在还没完全到位时就开始往下降，这两条指令之间没有障碍，可以放开。

第 8 行是关键的抓取点，150mm/sec 是降速，FINE 是必须的——如果这里用 CNT，机器人会在离工件几毫米的地方就开始闭合夹爪，抓空是大概率事件。第 9 行调子程序，把夹爪动作和等待逻辑封装出去，主程序保持干净。第 10 行抬升用 CNT50 而不是 CNT100，因为刚抓完工件，路径上可能有料台边缘，宁可慢一点。第 11 行转向用 J，因为两个位置之间是开阔空间。

子程序负责夹爪动作，带超时保护，这是仿真和真机都需要的东西：

1: ! GRIP_CLOSE —— 夹爪闭合，带 5 秒超时 2: R[1]=0 3: DO[1]=ON 4: LBL[10] 5: IF DI[1]=ON,JMP LBL[20] ; 到位信号来了就跳出 6: R[1]=R[1]+1 7: IF R[1]>50,JMP LBL[30] ; 循环 50 次约 5 秒，超时 8: WAIT 0.10(sec) 9: JMP LBL[10] 10: LBL[20] 11: DO[1]=OFF 12: END 13: LBL[30] 14: DO[1]=OFF 15: ABORT ; 超时中止，避免带病继续运行

R[1] 是计数器寄存器，DI[1] 是夹爪到位输入，DO[1] 是夹爪动作输出。超时保护这一段在实际项目里是必需品：如果夹爪卡住、气路没接、传感器坏了，没有超时的话程序会永远停在 WAIT 上，看起来像死机，排查起来毫无头绪。加了超时之后，至少会走到 ABORT，报错位置明确，省很多时间。数值 50 和 0.10 秒是配套的，改循环次数就要同步改等待时间，别只改一个。

4.5 仿真运行、节拍统计与碰撞检测

程序写完之后先在 T1 模式单步跑，每按一次启动走一行，眼睛盯着当前位置和下一个点位。这一步能抓出大部分点位错误——比如 P[3] 的 Z 值太低，机器人直接扎进料台。确认无误再切 AUTO 连续运行，跑三到五个循环看稳定性。

碰撞检测要打开。仿真里的碰撞检测会把机器人和工件、夹具、围栏之间的干涉标红并报警，这是它比真机强的地方：真机撞了才知道，仿真里还没撞就能看见。检测到碰撞之后别急着调点位，先看是哪两个对象碰的、发生在那一条指令上，再决定是改点位、改路径还是改姿态。我见过有人一看撞了就整体抬高十厘米，结果撞是不撞了，节拍多了五秒，抓取姿态也别扭了。

节拍统计在仿真报告里能直接生成，包括每个动作的耗时和总循环时间。看这个数据主要不是看总数，是看分布：如果某一条 J 指令占了总时间的四成，那说明这一段路径设计得不合理，可能需要加一个中间点或者改走直线。节拍优化的顺序通常是先调度再路径再加减速比，一上来就调加速度参数是最没效率的做法。

5. 避坑与排查：虚拟仿真里最容易翻车的五个地方

5.1 机器人一动不动，使能键按了也没反应

现象是所有界面看起来正常，程序也加载了，但一按运动键机器人纹丝不动，状态栏可能连报警都不给。原因通常分三层：最上层是模式不对，AUTO 模式下不响应手动运动指令，必须切 T1 或 T2；中间层是虚拟控制器还没完全启动，界面上控制器窗口出来了但内部状态机还在初始化，这时候按什么都没用；最下层是安全信号没复位，急停没有旋起、安全门没关，控制器处于保护状态。

排查按从外到内的顺序走。先看模式开关，再看控制器状态栏有没有"等待就绪"之类的提示，最后查 I/O 里的安全信号状态。仿真里的安全门状态有时候是独立于工作单元模型的，模型上看着关着，信号里是开的，这种不一致最坑人。解决方法是在工作单元里把安全门和信号显式绑定，门开就断信号，别让它各管各的。

5.2 点位全都在，但轨迹整体偏移

现象是程序能跑完，没有报警，但抓取点偏了十几厘米，姿态也可能歪了。第一嫌疑是工具坐标系没激活，程序里用了 TPROB 但是没有设 UTOOL_NUM，实际还在用默认的零点工具，所有点位相对法兰盘记录，整体偏移。第二嫌疑是用户坐标系号对不上，记点位时用的是 UF1，运行时是 UF0，两套坐标系的原点位置不同，偏得越多说明两个原点离得越远。

判断方法很直接：手动切到 TOOL 模式，只转姿态不平移，看手尖动不动。动就是 TCP 有问题，重标或者检查激活状态。如果 TCP 正常，再切到 USER 模式看原点位置对不对。这两个都确认了还有偏移，那就得看点位的记录方式——有些点位是在 JOINT 模式下记录的，存的是轴角度而不是笛卡尔坐标，这种点位换一个工具坐标系就完全变样，属于记录方式选错了，只能重教。

5.3 案例搬到别的工作单元就报错

现象是把程序文件拷到另一个工作单元，加载时报错，或者加载成功但运行到一半停下。原因集中在依赖项上：程序里引用的 I/O 信号编号、寄存器编号、用户坐标系、工具坐标系，在目标单元里可能根本不存在，或者含义完全不同。TP 程序本身只是一串指令，它依赖的那些编号是外部定义的，只搬程序不搬定义，等于搬了个空壳。

正确的搬运顺序是先搬配置再搬程序：I/O 分配表、寄存器用途表、坐标系标定数据、系统参数先在新单元里建好并且编号一致，然后再导入程序。案例包里之所以要单独放Doc和Frame_Data两层，就是为了这个场景——接手的人照着表重建配置，程序导进去就能跑。别指望"导入自动匹配"，编号对不上的时候它会静默地用一个错的映射，跑出来的结果看着像随机故障，实际是配置错位。

5.4 仿真节拍看着很漂亮，实际根本做不到

现象是仿真报告显示循环时间 18 秒，到真机上跑出来 26 秒，差得离谱。原因有三：一是仿真里没有建模负载惯量，工具和工件的重量对加减速的影响被忽略；二是没有考虑线缆拖拽和气管干涉，实际运行中这些阻力会拖慢动作；三是速度倍率设置不一致，仿真时用 100%，实操时操作员习惯性旋到 80%。第三条最容易被忽略，也最好解决。

处理办法是给仿真数据加修正系数。我一般按负载情况分档：轻载（工具加件小于额定负载三成）留 10% 到 15% 余量，中载留 20%，重载或者大惯量留 25% 以上。写进报告的时候把两组数都列出来，注明修正依据，比拍一个数字上去靠谱得多。另外在仿真里做节拍对比时，务必把两边的速度倍率都固定成 100%，否则比出来的只是倍率差，不是方案差。

5.5 备份恢复了，程序却不见了或者全是乱码

现象是从备份恢复之后，程序列表是空的，或者程序能打开但注释全是问号。原因是备份类型用混了：ASCII 备份和镜像备份的恢复方式不一样，镜像恢复是整机还原，覆盖全部内容；ASCII 恢复是按项导入，得手动选择要恢复哪些程序和参数，选漏了就是空的。乱码问题则多半出在字符编码上，程序注释里如果有非 ASCII 字符，跨环境读写时容易对不上。

稳妥的做法是两种备份都留，恢复时优先用镜像做整体还原，还原完了再用 ASCII 备份去核对具体程序的差异。注释尽量用英文或拼音，实在要用中文，确认导出的.LS文件用文本编辑器打开显示正常再交付。这套流程走一遍要十几分钟，但比事后发现程序没了重新写一遍要划算太多。备份不是做完就完事，得实际恢复一次验证过，才算真的备份成功。

6. 验收与答辩：怎么证明这套案例是真的能跑

到了这一步，工作单元能打开、程序能运行，但这不代表可以交了。验收要解决的是"别人能不能复现你的结果"这个问题。我的做法是写一张检查表，自己从头走一遍，走不通的地方就是案例的缺口。

这张表里最容易被跳过的是"异常处理有效"这一项。多数人只测正常流程，不测异常流程，结果交付出去的案例一遇到信号异常就卡死，学的人根本不知道该怎么办。测法很简单：在仿真里把夹爪到位的 DI 信号强制关掉，看程序会不会在五秒后走到 ABORT。会走，说明超时保护是有效的；不走，说明你写的那段保护逻辑根本没被执行到，可能标签跳转写错了。

答辩演示有个三分钟的脚本，比讲二十分钟 PPT 管用：第一分钟打开工作单元，用 TOOL 模式原地转一圈证明 TCP 标定有效，这一下就把"我是真做过"立住了；第二分钟切 T1 单步跑完一个抓放循环，边走边报出当前用的是哪条指令、为什么用 FINE；第三分钟切 AUTO 连续跑三个循环，同时把节拍报告和碰撞检测结果切出来。三分钟里没有一句话是空话，全是可验证的动作和数据。

如果时间允许，再加一个"故意出错"的环节：把某个中间点的 CNT 值临时改到 100，让机器人切角撞上料台边缘，报警弹出来之后现场改回去。这个演示的说服力远超任何解释，因为它证明你不仅知道怎么让它跑通，还知道它为什么会跑不通。评审老师最想看的往往就是这个——一个只会照着步骤操作的人，和一个知道每一步为什么这么做的人，差别全在故障处理上。

从那以后我每次交付案例前，都会把那张检查表从头到尾走一遍，哪怕只改了一个点位坐标。改点位这事看着小，但它可能让原本 FINE 的位置变成 CNT 过渡，也可能让抬升路径擦到料台边角，连锁反应比想象中大。希望帮到你。

本文还有配套的精品资源，点击获取