1. 课程导入与迁移校核总览
在 FANUC 机器人离线编程的实际工程中，ROBOGUIDE 承担着“先在电脑里把机器人跑通，再搬到现场”的角色。但很多工程师会遇到一个尴尬局面：仿真里轨迹漂亮、节拍达标，程序拷到真实控制柜后却出现 TCP 偏差、奇异点报警、I/O 不对应，甚至整段程序无法启动。所谓项目程序迁移，就是把在 ROBOGUIDE 工作单元中验证过的 TP 程序、系统配置、坐标系与 I/O 定义，完整、可控地转移到真实机器人控制器（或另一台仿真控制器）的过程；而校核，则是在迁移前后用一套可复现的方法，确认“程序能运行、轨迹对得上、信号接得通、安全有保障”。迁移是动作，校核是判据，两者必须成对出现。
本课程围绕一条主线展开：从 ROBOGUIDE 工程中识别哪些内容需要迁移，如何迁移，迁移后如何逐层验证，直到交付一份可追溯的迁移校核记录。第 1 章先建立全局认知，后续章节再逐项深入。
一、迁移到底迁移什么
初学者常以为“迁移就是把 .TP 文件复制过去”，这是最常见的误区。ROBOGUIDE 工作单元里真正影响程序能否在现场复现的，至少包含四类对象：
- 程序本体：TP 程序（.TP/.LS）、宏程序、KAREL 程序（.PC）。它们决定动作序列与逻辑。
- 系统配置：系统变量、$SCR_GRP 等运动相关参数、用户坐标系 UFRAME、工具坐标系 UTOOL、负载 SCHEDULE。
- I/O 定义：数字/模拟/组 I/O 的机架（Rack）、插槽（Slot）、起始点（Start）、状态（Enable/Simulate），以及 I/O 注释与逻辑分配。
- 环境与标定数据：机器人型号与安装方式、外部轴配置、干涉区定义、参考位置（Reference Position）。
只迁移程序本体，等于把“动作脚本”搬走却丢掉了“坐标系和信号字典”，现场必然对不上。因此迁移的对象清单必须在动手前就确定。
二、典型场景
迁移校核并非只有一种情形，常见的有：
- 仿真到实机：ROBOGUIDE 验证完成后下发到现场控制柜，这是最主要场景。
- 实机到仿真：把现场已有程序回读到 ROBOGUIDE，用于改造、节拍优化或故障复现。
- 控制器到控制器：同型号设备复制、备机切换，或旧柜升级到新柜。
- 版本升级迁移：ROBOGUIDE 或控制器软件版本变化后，重新校核兼容性。
不同场景的迁移方向、风险点和校核重点不同，但底层方法一致：先对齐配置，再迁移程序，最后分层验证。
三、工作流程总览
下图给出本节的核心视图：迁移校核不是单步操作，而是一条“配置对齐—程序迁移—分层校核—交付归档”的链路，每一层校核失败都要回到对应环节修正，而不是在现场反复试错。
四、分层校核：为什么不能一步到位
现场最危险的做法是“程序一导入就直接自动运行”。正确做法是把校核拆成递进的层次，每层只回答一个问题：
- 语法与调用层：程序能否被控制器正常加载？有无未定义的程序名、宏、标签？在 ROBOGUIDE 中可用“程序校验/编译”功能先筛一遍，现场则观察示教器报警历史。
- 坐标系与 TCP 层：UFRAME 与 UTOOL 是否与仿真一致？可用六点法或直接比对数值。示例：仿真中 UTOOL[1] 的 X=0、Y=0、Z=180.0 mm，现场若显示 Z=175.0 mm，说明工具标定或迁移有偏差，必须先修正再谈轨迹。
- I/O 与逻辑层：逐个核对机架、插槽、起始点。例如仿真中夹爪开合信号为 DO[1]，现场若实际接在 DO[5]，程序逻辑就会错位。可用“强制输出”逐点验证。
- 轨迹与节拍层：先单步、再空运行、再低速（如 10% 倍率）、最后全速。观察 TCP 实际路径与仿真路径的偏差，记录关键点位置。
- 安全与干涉层：确认急停、安全门、干涉区（DCS/干涉区）在真实环境下有效，必要时用低速接近极限位置验证。
任何一层不通过，都应回到对应环节修正，而不是靠现场“调一调”掩盖问题。这也是图中那条红色回流箭头所表达的含义。
五、学习路径与最终交付物
本课程后续将按“认知—操作—验证—交付”的路径推进：先理解迁移对象与风险，再掌握 ROBOGUIDE 侧的导出与配置方法，然后学习控制器侧的导入与校核操作，最后形成可复用的迁移校核记录。学习过程中建议始终带着一个真实或假设的工作单元来练习，例如一台 R-2000iC/165F 配双工位夹具的搬运单元。
本课程最终要交付的，不是“程序跑起来了”这一句话，而是一份可追溯的成果包，至少包含：
- 迁移对象清单（程序、配置、I/O、标定数据逐项列出）。
- 迁移前后差异对照表（重点记录 UFRAME、UTOOL、I/O 分配的变化）。
- 分层校核记录（每层的检查项、实际结果、判定结论）。
- 程序与配置的备份文件及版本标识。
- 遗留问题与风险说明（哪些项未完全验证、原因是什么）。