简介：这份ROBOGUIDE虚拟仿真案例文件面向已具备FANUC机器人基础操作知识、希望用现成项目巩固示教编程与仿真运行的学习者，提供可载入软件的基础操作练习载体，减少从零搭建虚拟工作站的时间，并便于在无实体设备条件下复现操作流程。项目由ROBOGUIDE V9.4创建，略高或略低版本也能兼容，但建议用相同版本打开；受版本差异影响，机器人、工具与工装模型可能不同，操作逻辑一致。压缩包约27.66MB，共1个文件，主要为XML配置文件，用于承载仿真项目相关配置信息。案例覆盖虚拟机器人系统创建、基础工作站外围设备模型添加、示教编程及仿真运行等环节，适合按项目结构逐项练习，并对示教点、轨迹与运行结果进行对照检查。已有179人学习，可作为FANUC机器人入门阶段的虚拟仿真练习素材。
1. 先用虚拟仿真把示教编程练成肌肉记忆，再谈上机
第一次站在 FANUC 机器人示教器前面，最难受的不是记不住按键，而是不敢按——真机零点、软限位、干涉区都摆在那，按错一个键就是撞机。ROBOGUIDE 的虚拟仿真案例文件解决的正是这道心理门槛：它把一个能完整跑起来的虚拟工作单元打包给你，控制器是虚拟的，机器人在屏幕里动，示教器就是那块面板，你在里面点动、建程序、改运动指令、看节拍，全都不用碰真机。这份资源属于仿真工作单元加基础示教程序的组合包，面向刚接触 FANUC 机器人示教编程的在校生和新员工、需要做离线验证的调试工程师，以及要给新人做带教的集成人员。它的价值不在某个高级算法，而在于把从建站、点动到写程序的整套基本功压缩到一台笔记本上反复练，练到闭着眼都能切坐标系为止。
2. 环境搭建与工作单元建立：版本、控制器和案例文件的对应关系
拿到案例文件的人里，第一步就卡住的不少，而卡住的原因大多不是文件坏了，是 ROBOGUIDE 主程序版本、虚拟控制器型号、机器人型号这三者对不上。ROBOGUIDE 的结构是「主程序 + 若干可选虚拟控制器」，主程序版本决定了你能选哪些控制器，控制器又决定了案例里能用哪些指令集和 I/O 规模。这一章按装机顺序，从版本选型讲到打开案例后的第一轮检查，目标是在半小时内得到一个能稳定运行、后面可以放心折腾的虚拟工作单元。
2.1 主程序、虚拟控制器与机器人型号的匹配
选型这件事有个很朴素的判断顺序：先看案例文件里用的是哪个机器人系列，再看它挂在哪个控制器上，最后倒推需要哪一档 ROBOGUIDE。机器人型号决定了臂展、可达范围、DH 参数和基座尺寸，控制器型号决定了运动指令的插补能力和 I/O 点数，主程序版本决定了前两者能不能被正确加载。高版本主程序通常能向下打开低版本工作单元，反过来基本会直接报错，所以宁可装高一档，不要装低一档。
| 案例中的机器人系列 | 对应的虚拟控制器 | 典型应用场景 | 选错后的直接表现 |
|---|---|---|---|
| 小型六轴（如 LR Mate 系列） | R-30iB Mate 类 | 机床上下料、小型搬运 | 打开时提示控制器不支持，或机器人在单元里无法上电 |
| 中型通用六轴（如 M-10iD 类） | R-30iB / R-30iB Plus | 通用搬运、装配、码垛 | 可达范围对不上，部分点位标成不可达 |
| 弧焊专用机型 | R-30iB Plus 加弧焊软件选项 | 焊接轨迹示教与节拍评估 | 焊接指令变成非法指令，程序行标红 |
装之前有三件事先处理掉：系统区域设置里小数点必须是点号，不能是逗号，否则运动指令里的速度值会解析成两个参数，这种问题排查起来很折磨人；安装路径用纯英文，比如D:\ROBOGUIDE，路径里有中文或空格是虚拟控制器起不来的经典原因；装完先别急着开案例，新建一个空白工作单元把虚拟示教器启动一次，确认环境本身是干净的。
2.2 从空白工作单元到案例文件导入的操作步骤
标准的建站流程在 ROBOGUIDE 的单元向导里，按顺序走完这一串即可。这里我用「步骤 + 参数说明」的方式写，因为这属于仿真类资源，跑的是图形界面，没有可抄的命令行。
- 启动 ROBOGUIDE，选择新建工作单元（New Cell）。
- 在应用模板页选择控制器软件选项。案例是通用搬运就选 HandlingTool，是弧焊就选带弧焊选项的控制器，模板决定了后续程序里能调用的指令集。
- 选择机器人型号。这里必须和案例文件里的型号逐字一致，包括斜杠后面的负载规格，比如 M-10iD/12 里的 12 指的是 12 kg 负载，改成 M-10iD/8 之后整机的惯量和运动参数都会变。
- 选择虚拟控制器版本。同一代控制器会并列好几个小版本，跟案例保持一致最稳；如果只是练基础示教，选同代里较高的版本兼容性更好。
- 命名工作单元并指定保存路径。路径同样不要带中文，单元文件后续要反复读写，中文路径在部分版本上会导致保存时生成零字节文件。
- 完成向导后等待虚拟控制器启动，首次启动通常要几十秒，期间会拉起一个后台进程，这时候别重复点击，容易起两个实例互相抢资源。
- 案例文件是通过打开工作单元的方式载入的。打开时如果弹出控制器重新连接的询问，选择保持原控制器，让它沿用案例里已有的控制器配置，而不是新建一个。
提示：新建完成之后先另存一份副本，命名为「练习用」。案例文件是你的基准参照，后面所有改点位、改速度、改 CNT 值的操作都在副本上做，出问题直接回到基准，省掉一半返工。
2.3 打开案例后的第一轮依赖检查
案例文件能打开不代表能跑。它本质上是把别人机器上的配置打包过来，而这些配置在你本机上可能有一半对不上。打开之后按下面这张表逐项过一遍，每项都能在示教器或单元浏览器里查到。
| 检查项 | 查看位置 | 不一致时的表现 |
|---|---|---|
| 机器人型号与臂展 | 单元浏览器里的 Robot 节点 | 模型外观和案例截图不一致，部分点位不可达 |
| 控制器型号与软件选项 | 单元浏览器里的 Controller 节点 | 程序里出现红色非法指令 |
| 工具坐标系 UTOOL | 示教器 MENU → SETUP → Frames | TCP 偏离法兰中心，插拔类动作全部错位 |
| 用户坐标系 UFRAME | 同上 | 所有基于工件的点位整体平移或旋转偏移 |
| 负载设定 Payload | MENU → SYSTEM → Motion | 节拍估算偏乐观，挪到实机会触发过载报警 |
| 数字量 I/O 分配 | MENU → I/O → Digital | 程序里的 DI/DO 编号和外围设备对不上 |
工具坐标系和用户坐标系这两项最容易被忽略。案例里如果用了自定义 UTOOL，而你这边仍是默认的 UTOOL 0，仿真里机器人照样能动，只是末端走的轨迹整体偏出去了，肉眼看不太出来，等到上机才发现第一个点就差几厘米。检查方式很简单：在示教器上切到 TOOL 坐标系点动，看末端执行器的运动方向和实际工具轴向是否一致。不一致就去 Frames 里重新设定 TCP 或者调用案例自带的坐标系编号。
3. 示教编程核心：坐标系、运动指令与程序结构
虚拟仿真练的就是三个动作：把机器人点到位、把点住记下来、把点串成程序。这三个动作对应的技术点分别是点动坐标系的选择、运动指令的参数设定、以及程序里的寄存器和逻辑控制。这一章按这个顺序展开，每个环节都给出在虚拟示教器上的具体按键路径和参数含义，跟着走一遍，一个完整的取放程序就能跑起来。
3.1 五种点动坐标系与切换时机
示教器的 COORD 键循环切换点动坐标系，按住 SHIFT 再按 COORD 反向切换。切换的意义在于，同一个方向键在不同坐标系下驱动机器人的方式完全不同，用错坐标系点出来的点，位置看似对，姿态大概率是歪的。
| 坐标系 | 显示 | 方向和谁对齐 | 我一般什么时候用 |
|---|---|---|---|
| JOINT | JOINT | 单根轴独立旋转 | 回原点、避开奇异点、单轴微调 |
| WORLD | WORLD | 机器人基座的世界坐标 | 大范围空走、粗定位、远离工件的移动 |
| TOOL | TOOL | 当前工具坐标系的轴向 | 沿工具轴进给、插拔、拧紧、贴合面接近 |
| USER | USER | 用户自定义的工件坐标系 | 在工装上示教点位、批量复制同一套动作 |
| JGFRM | JGFRM | 用户自定义的点动方向 | 斜面、倾斜工装上的方向调整 |
新手最容易犯的错是全程用 JOINT 点动。关节坐标系下每按一次方向键，末端走的是一段弧线，看着能动，但根本控制不了末端的直线方向，示教出来的接近点全是歪的。正确的做法是：从远处移动到工件附近用 WORLD 或 JOINT，进入接近段之后立刻切到 TOOL 或 USER，最后那几十毫米一定要在 TOOL 坐标系下走直线。
速度倍率在虚拟仿真里同样要设。示教器上的倍率键可以从 1% 调到 100%，仿真里不存在撞坏东西的成本，很多人直接拉满，但上机时人的反应速度是按低速练出来的。我一般把首次示教固定在 10%～25%，把「到位前松手」这个动作练成条件反射，虚拟仿真里练出的手感和真机是通用的。
3.2 运动指令、速度与终止类型的参数取舍
FANUC 的运动指令主要就四条：J、L、C、A。J 是关节插补，走的是各轴协同的最短路径，速度快但轨迹不可控；L 是直线插补，末端沿直线走；C 和 A 是圆弧插补，C 需要当前点、中间点、目标点三个点，A 只需要一个中间点，两者的区别在于 C 的可控性更好。速度单位和终止类型是这两条指令背后最容易出错的两个参数。
| 指令 | 插补方式 | 速度单位 | 适用动作 | 注意事项 |
|---|---|---|---|---|
| J | 关节插补 | 百分比 % | 空走、回原点、大跨度转移 | 轨迹不可控，绝对不能用于接近工件 |
| L | 直线插补 | mm/sec | 接近、插入、涂胶、直线搬运 | 速度过高时拐角处惯性大 |
| C | 圆弧插补 | mm/sec | 倒角、圆弧过渡、圆形轨迹 | 三点不能共线，否则报错 |
| A | 圆弧插补 | mm/sec | 需要经过中间点的圆弧 | 中间点偏离过大时精度下降 |
终止类型只有两类：FINE 表示精确到位，机器人会减速停在该点再执行下一条；CNT 表示提前过渡，后面的数字 0～100 决定了提前量，数值越大过渡越平滑、轨迹偏离越大。这个参数是仿真和实机差异最大的地方——仿真里 CNT100 看起来又快又顺，实机上因为惯性和减速机背隙，末端实际轨迹会往外甩出一截。
/PROG PICKPLACE /ATTR OWNER = MNEDITOR; COMMENT = "pick and place demo"; /MN 1: J P[1] 100% FINE ; 2: L P[2] 500mm/sec FINE ; 3: WAIT 0.50(sec) ; 4: DO[1]=ON ; 5: L P[3] 300mm/sec CNT50 ; 6: L P[4] 300mm/sec CNT100 ; 7: DO[1]=OFF ; 8: J P[1] 100% FINE ; /POS P[1]{ GP1: UF : 0, UT : 1, CONFIG : 'N U T, 0, 0, 0', X = 900.000 mm, Y = 0.000 mm, Z = 620.000 mm, W = 180.000 deg, P = 0.000 deg, R = 0.000 deg }; /END上面这段是 TP 程序导出成文本后的样子，也就是后面进阶章节要用的 LS 格式。逐行说明一下：第 1 行用 J 指令回安全点 P[1]，速度 100%、FINE 精确到位，这是每个循环的起点；第 2 行用 L 指令直线下降到抓取点 P[2]，速度 500 mm/sec，同样用 FINE，因为抓取动作必须精确停在点上；第 3 行是一个 0.5 秒的等待，用来模拟夹爪闭合的时间；第 4 行把数字输出 DO[1] 置 ON，驱动夹爪；第 5、6 行是两段连续的搬运路径，用 CNT50 和 CNT100 做平滑过渡，注意这里速度降到 300 mm/sec，因为带着工件；第 8 行回到起点，一个完整循环结束。
关键参数就三个：速度、终止类型、位置编号。速度按动作性质选，空走可以高，带载和接近必须低；终止类型按是否需要精确停点选，凡是抓取、放置、插入这类动作一律 FINE，纯路径过渡才用 CNT；位置编号 P[n] 是示教时记录下来的，修改点位就是修改这个编号对应的坐标值，不需要重写程序。
3.3 寄存器、逻辑指令与程序分支
基础示教到这一步就够了，但真正能用的程序一定有逻辑。FANUC 的寄存器分几类：R[i] 是数值寄存器，存整数；PR[i] 是位置寄存器，存一个完整的六维坐标，可以做偏移运算；DI/DO 是数字量输入输出，和外围设备握手；RI/RO 是机器人专用输入输出，通常接 PLC；UI/UO 是系统级信号，控制启动、暂停、复位这些动作。
1: L P[5] 200mm/sec FINE ; 2: WAIT DI[3]=ON ; 3: IF R[1]>3, JMP LBL[99] ; 4: R[1]=R[1]+1 ; 5: PR[1]=P[5] ; 6: PR[2]=PR[1] ; 7: PR[2,3]=PR[2,3]+50 ; 8: L PR[2] 200mm/sec FINE ; 9: LBL[99] ;这段的重点在第 5 到第 7 行。先把示教点 P[5] 整体赋给位置寄存器 PR[1]，再复制到 PR[2]，然后把 PR[2] 的第三个分量（Z 方向）加 50 mm，得到一个抬高 50 mm 的新位置。这种写法在需要按层码垛或者按间距排列多个点位时非常省事——一份示教点位，靠寄存器偏移生成一整套路径，改间距只改一个数字。第 3 行的条件跳转配合第 4 行的计数，构成一个最简单的循环次数控制：R[1] 大于 3 就跳到 LBL[99] 结束，否则计数加一继续执行。
注意：位置寄存器的下标从 1 开始，但分量下标是从 1 到 6 依次对应 X、Y、Z、W、P、R，写偏移的时候别弄错分量位置。偏移量单位是毫米和度，写 50 表示 50 mm，不是 0.05。
4. 仿真运行与验证：碰撞检测、节拍估算和 I/O 联调
程序写完之后，虚拟仿真的真正价值才开始体现——它可以让你在零成本的前提下，把可能撞的、可能超时的、可能信号对不上的问题全部暴露一遍。这一章讲三个验证手段：碰撞检测怎么开、节拍怎么估、I/O 怎么联调。三个都过一遍，这份案例文件才算真正用透了。
4.1 碰撞检测与干涉区设定
碰撞检测在 ROBOGUIDE 里是默认可以开启的开关，开启后机器人模型、工具模型、工作台上的工装模型之间会做实时干涉判断，一旦接触就弹出报警并暂停仿真。设定流程一般是三步：先把工作台、夹具、料框这些外围模型导入或者用内置的基本体搭出来，尺寸按实际工装来，偏差太大会导致误报或漏报；然后在碰撞检测设置里把这些模型勾选为参与检测的对象；最后设定一个安全距离，机器人运动到距离干涉体小于该值时提前报警，而不是等真正撞上才报。
这套检测的价值在于，它能抓出那些在示教阶段肉眼看不出来的问题。比如工具在某个姿态下，法兰后端会扫过夹具的上沿；比如机器人为了绕开一个障碍，某个关节反转到了极限位置附近，下一步就超程。这些问题在虚拟环境里跑一遍就能暴露，而真机上暴露的代价是一次撞机加一次维修。
报警读法也要留意。仿真里触发碰撞后会给出报警码和触发对象名称，对照单元浏览器里的模型列表就能定位是哪两个部件干涉。常见的一类报警是运动学层面的，比如目标点超出可达范围或者经过奇异点，这类报警不涉及碰撞，但要判断是点位本身设错了，还是路径中间段绕不过去，解决办法通常是增加一个中间过渡点，把一段长距离运动拆成两段。
4.2 节拍估算与 Cycle Time 报告
节拍是仿真最容易给出、也最容易被误信的数据。ROBOGUIDE 的节拍统计一般有两种方式：一是单次运行计时，记录一个完整循环从开始到结束的耗时；二是循环统计，连续跑若干个循环取平均值，排除首次运行的启动开销。
读这份报告的时候要盯住四件事。一是速度倍率，仿真默认按 100% 跑，实机很多时候受安全和工艺限制只能跑 50%～70%，报告里的节拍要按实际倍率折算。二是负载设定，Payload 里填的重量如果比实际小，仿真算出来的加减速曲线会偏激进，节拍虚快。三是 CNT 值，CNT 越大过渡越平滑、节拍越短，但实机上轨迹偏离也越大，节拍和精度是一对需要平衡的量。四是等待指令，程序里所有 WAIT 的时间和外部信号响应时间都会被计入，这部分在仿真里往往是理想值，实机上要加上 PLC 扫描周期和气缸动作时间。
我一般的习惯是，仿真节拍乘以 1.2 到 1.3 的系数作为实机的预估上限，如果这个上限仍然满足产线要求，方案才算成立。系数具体取多少，取决于机器人负载率和动作的精细程度，轻载高速的动作系数可以小一些，重载或者需要精确停点的动作系数要留足。
4.3 I/O 与外围设备信号联调
虚拟环境里的 I/O 联调，本质是把真实产线上由 PLC 完成的那部分逻辑，用仿真手段临时补上。ROBOGUIDE 支持手动强制 DI/DO 的状态，也支持用简单的仿真信号源模拟周期性输入。做法是：先在示教器的 I/O 配置里把 DI/DO 的名称和编号按案例定义好，名称建议直接用功能命名而不是 DI01、DI02 这种，比如「夹爪闭合到位」「上料完成」，后面程序里引用时可读性好很多；然后在仿真运行时手动切换 DI 状态，观察程序的 WAIT 指令是否能正确放行。
系统信号这块要特别注意 UI/UO。UI 里的启动、暂停、复位、报警确认这些信号，在虚拟示教器上对应面板按钮，仿真时点面板和实机按按钮走的是同一套逻辑。如果案例程序里用了 UI 信号做启动互锁，在仿真里就要按对应的按钮来触发，直接跑程序可能会一直卡在等待状态。RO 信号一般是给 PLC 的状态反馈，仿真里可以用它的状态判断程序是否走到了某个阶段，作为联调时的观测点。
5. 避坑与常见问题排查：五条踩坑记录
这一章是我自己在拆这类仿真案例文件时反复踩到的五条，按层面分成三组，每条都按现象、原因、解决三段的顺序写，碰到同类问题时可以直接对号入座。
5.1 环境与文件层：装完打不开，开了跑不动
现象一：虚拟控制器启动到一半就退出，示教器界面一直灰着，日志里没有明显报错。
原因是安装路径或者用户目录里带了中文和空格。虚拟控制器在启动时会按路径去加载一批配置文件，遇到非 ASCII 字符时路径解析失败，进程直接终止，但外层界面不会给出明确提示。
解决办法是把 ROBOGUIDE 卸载后重装到纯英文路径，同时确认系统的临时目录和用户目录也是英文。另外还有一个高频原因：杀毒软件把虚拟控制器的后台进程当成可疑行为拦截了，表现同样是启动到一半退出。装完之后把 ROBOGUIDE 的安装目录和它的工作目录都加进白名单，这个问题基本就绝迹了。
现象二：案例文件能选中，但打开时报版本不兼容，或者打开后程序里一堆红色非法指令。
原因是主程序版本低于案例文件的制作版本，或者控制器软件选项没选对。ROBOGUIDE 的工作单元里带着控制器版本信息，低版本主程序不认识高版本的配置结构，只能报错。
解决办法是先确认案例是用哪一代控制器做的，装同代或者更高一代的主程序。如果版本没法升级，那就退一步：新建一个空白工作单元，把案例里的程序通过文本方式导入，点位数据手工核对一遍。这种降级方案能跑通基础示教，但会丢掉一部分和控制器强相关的配置。
5.2 示教层：点位看着对，跑起来偏
现象三：仿真里末端走位看着正常，程序导到实机之后第一个点就偏出去几厘米。
原因基本锁定在工具坐标系和负载设定上。案例里定义了自定义 UTOOL，而你这边仍是默认值，仿真时因为模型本身不带偏差，肉眼很难发现；实机上 TCP 一旦和真实工具中心不重合，所有插拔、贴合类动作都会整体偏移。负载没设对也是同理，轻载设定下机器人的加减速曲线更激进，高速动作时末端实际停位会比程序点更「冲」一点。
解决办法是打开案例后第一件事就核对 UTOOL 编号和 TCP 数值，在示教器上用 TOOL 坐标系点动确认方向正确，再核对 Payload 里的重量和重心位置。这两项确认无误之后再动程序，后面的所有调试才有意义。
现象四：仿真里拐角过渡很顺，实机在拐角处过冲，撞到了夹具边缘。
原因是 CNT 值设得过大。CNT100 意味着机器人几乎不减速就切向下一个点，仿真里因为模型是刚体、没有真实的伺服跟随误差，看起来又快又好；实机上由于惯性和减速机背隙，末端会沿切线方向甩出去一段。
解决办法是把所有需要精确停点的位置一律改成 FINE，纯路径过渡的位置把 CNT 降到 30～50 之间试跑，观察拐角处是否还有过冲。这里没有通用值，只能按实际负载和速度调，负载越大、速度越高，CNT 就应该越小。
5.3 验证层：仿真和实机对不上
现象五：仿真节拍显示 18 秒，实机跑下来要 26 秒，差了将近一半。
原因是仿真环境里的几个理想化假设同时叠加了。速度倍率按 100% 算，实机可能只跑 60%；等待指令里的时间按理想值给，没算 PLC 扫描周期和气缸实际动作时间；负载设轻了，加减速算得偏快；再加上实机的伺服响应和机械磨损，每一项都贡献一点差距，加起来就相当可观。
解决办法是建立一个折算习惯：先把仿真速度倍率调到和实机一致，再把所有 WAIT 的时间按实测值往上修，负载补到真实值，最后整体乘一个 1.2～1.3 的安全系数。用这个修正后的数据去评估产线能力，结论才站得住。
6. 进阶：把 LS 文件当核对表，做一轮上机前的离线回放
仿真跑通、程序看着没问题，接下来最危险的一步是把程序挪到实机。这一步出问题的根源，几乎都是「仿真里的配置」和「实机上的配置」在心里被默认为一致了。我后来养成一个习惯：上机之前，把仿真里的 TP 程序导出成 LS 文本，用脚本把里面的点位坐标和坐标系编号全部抽出来，做成一张核对表，再和实机上的对应值逐项比对。
LS 文件的结构很规整，程序段在/MN和/POS之间，点位数据在/POS之后，每个P[n]块里都带着 UF、UT、CONFIG 三个关键字段和 XYZWPR 六个坐标值。用一段几十行的脚本就能把这些字段全部提取成表格。
import re # 读入导出的 LS 文本，按 POS 段切分 with open("PICKPLACE.LS", "r", encoding="utf-8", errors="ignore") as f: text = f.read() pos_block = text.split("/POS")[1] # 每个点位以 P[n]{ 开头，匹配到对应的 }; points = re.findall(r"P\[(\d+)\]\{(.*?)\};", pos_block, re.S) rows = [] for idx, body in points: # 抽取 UF / UT 编号，这两个值决定点位在哪个坐标系下解释 uf = re.search(r"UF\s*:\s*(\d+)", body) ut = re.search(r"UT\s*:\s*(\d+)", body) # 抽取六个坐标分量 vals = dict(re.findall(r"([XYZ WPR])\s*=\s*(-?\d+\.?\d*)", body)) rows.append({ "point": f"P[{idx}]", "UF": uf.group(1) if uf else "?", "UT": ut.group(1) if ut else "?", "X": vals.get("X"), "Y": vals.get("Y"), "Z": vals.get("Z"), "W": vals.get("W"), "P": vals.get("P"), "R": vals.get("R"), }) for r in rows: print(r)这段脚本做三件事：把/POS段从整个文件里切出来，用正则匹配每一个P[n]{...}块，再从块里分别抓 UF/UT 编号和六个坐标分量。跑完之后输出一张表，一行一个点位，字段对齐。参数上要注意的是正则里的[XYZ WPR]中间那个空格，实际文件里字段之间用的可能是制表符，稳妥的写法是把字符集写成[XYZ\sWPR]再在取值时去掉空白。另一个坑是负数和小数的匹配，坐标值可能带负号、可能只有整数部分，-?\d+\.?\d*这个模式能覆盖绝大多数情况，但如果遇到科学计数法就要补上指数部分。
拿到这张表之后，比对的重点不是坐标值本身，而是 UF 和 UT 这两列。坐标值不一致很好发现，照着改就行；真正麻烦的是坐标系编号不一致——同样的 XYZWPR 数值，在 UF 0 和 UF 1 下解释出来是完全不同的两个位置，而程序看起来一切正常。所以核对的顺序应该是：先确认所有点位的 UF/UT 与实机一致，再逐个比坐标值，最后确认 CONFIG 字段（关节配置）没有在搬运过程中翻转变号，翻号会导致实机走到同一个点位时姿态完全不同，甚至中途撞上工装。
这套流程我现在是强制执行的，哪怕只是改了一个点位也会重新导出比对一遍。血泪经验来自一次只改了一个 Z 值就上机的经历：改的时候在 USER 坐标系下操作，导出后忘了检查 UF 编号，实机跑到那个点直接偏了十几厘米，幸好速度倍率压得低。从那以后我每次上机前都强制走一遍这个流程——导出 LS、跑脚本、比对 UF/UT、再比坐标，四步走完才允许按下启动。希望帮到你。
本文还有配套的精品资源，点击获取
