FANUC机器人PR[i]位置寄存器实战：坐标系转换与视觉引导全解析

做机器人调试这些年，FANUC的PR[i]位置寄存器几乎每天都在碰。但说实话，真正能把PR[i]用明白、尤其是在坐标系转换场景下不出错的人，并不是多数。很多朋友卡在“赋值没问题、一用就乱跑”这个阶段，归根到底是对位置变量的底层逻辑缺乏完整认知。这篇东西不打算讲手册上那点皮毛，我直接把从入门到接项目踩过的坑、验证过的套路全部摊开，从最基础的LPOS/JPOS区别，到手写坐标系转换模板，再到视觉引导场景的完整案例，一次说透。

1. 位置变量PR[i]到底是什么东西

1.1 位置数据的两种“长相”：LPOS和JPOS

FANUC机器人里，任何位置点本质是一组数字，但根据表达方式不同，分成两大类：关节位置JPOS和笛卡尔位置LPOS。

JPOS记录的是机器人6个轴的关节角度，格式是J1、J2、J3、J4、J5、J6，可能还有附加轴。LPOS记录的是工具末端在某个坐标系下的空间坐标和姿态，格式是X、Y、Z、W、P、R。这里W、P、R是欧拉角，分别对应绕X、Y、Z轴的旋转量。

很多初学者最容易犯的第一个错误，就是把LPOS和JPOS当成可以随意互换的数据。实际上它们只是同一个物理位置的两种数学表达。就像同一个地址，用经纬度描述和用“某市某区某街道门牌号”描述，信息等价但格式完全不同。两者之间靠机器人的正解（关节→笛卡尔）和逆解（笛卡尔→关节）算法转换。

1.2 PR[i]寄存器的存储结构

PR[i]是FANUC专门为位置数据设计的寄存器，编号从PR[1]开始，一般机器人能开到几百个。每个PR[i]内部其实是一个结构体，里面同时保存了LPOS和JPOS两套数据。

关键点来了：当你用示教器手动修改某个PR[i]的LPOS坐标时，系统会自动运算更新对应的JPOS；反过来你改JPOS，LPOS也会同步重算。这个自动同步机制在手动操作时没问题，但在程序里通过赋值语句写PR[i]时，经常出现“只更新了一半”的情况，后面我会详细讲这个坑。

1.3 位置变量的“快照”属性

PR[i]还有一个容易被忽略的属性：它是“快照”型数据。当你把机器人当前点写入PR[i]时，存的是那一刻的位置状态。如果之后机器人移动了，PR[i]里的数据不会跟着变，除非你重新写入。

这听起来像废话，但实际使用中很多人会犯迷糊。比如有人在循环里反复使用同一个PR作为目标点，却忘了每次循环都要先更新PR的值，结果机器人在第二次循环时还往第一次的位置跑。这种问题排查起来很费时间，因为程序语法完全正确，但逻辑上漏了“刷新”那一步。

2. 位置赋值：五种方式与适用场景

2.1 示教器手动赋值

按下示教器上的“位置”键，选择PR[i]，可以直接手动输入坐标值。这种方式适合单点测试、固定点位预设。操作很简单，但要注意：手动输入时一定要确认当前激活的用户坐标系UF和工具坐标系UT，因为LPOS的X、Y、Z、W、P、R值都是相对于这两个坐标系而言的。

我见过有人在UF[1]下输入了一个点的坐标，然后程序调用时用的是UF[0]，机器人直接跑到完全不同的位置。这个问题极其隐蔽，因为PR[i]数据本身没错，错的是参照系不一致。

2.2 程序内LPOS直接赋值

在TP程序里，可以用类似这样的指令：

LPOS[1] = LPOS[2]

或者：

PR[10, 1] = 500.0

第一条是把PR[2]的笛卡尔坐标赋值给PR[1]，第二条是把PR[10]的X分量直接设为500.0毫米。

直接赋值的好处是灵活，适合在运行中动态修改目标点。但这里有一个重要规则：直接修改LPOS后，PR[i]内部的JPOS数据不会自动同步。如果你后续用这个PR[i]执行关节运动（J指令），机器人用的是JPOS数据，还是旧的，结果就会跑偏。

2.3 当前位置写入

这个是最常用的方式，TP指令是：

PR[i] = LPOS

或者带工具和用户坐标系的写法：

PR[i] = LPOS[UT:1, UF:2]

执行这行指令时，机器人会把当前工具末端在指定坐标系下的笛卡尔位置写入PR[i]，同时自动更新JPOS。这是最“安全”的赋值方式，因为系统帮你做了完整的数据同步。

2.4 运算赋值：位置加减法

FANUC系统里，PR[i]可以直接做加减运算：

PR[3] = PR[1] - PR[2]

这条指令的含义是PR[1]的位置减去PR[2]的位置，结果存到PR[3]。但这个“减法”不是简单的XYZ分量相减，而是涉及旋转矩阵的复合运算。

用大白话说，PR[1] - PR[2]可以理解为：从PR[1]出发，沿着PR[2]的反方向移动后得到的新位置。这在做相对位置偏移、镜像对称位置计算时非常有用。比如你在A点抓取，B点是码垛放置点，如果工件在传送带上有偏差，可以用“基准抓取点 + 偏差量”的方式动态计算实际放置点。

2.5 后台逻辑/视觉系统写入

很多带视觉引导的项目，会通过以太网、Devicenet或机器人自身的视觉系统，把视觉识别的目标坐标直接写入PR[i]。这类写入通常是后台任务完成，前台TP程序只需要等待“数据刷新完成”标志位，然后直接调用PR[i]运动。

这里要特别提醒：视觉系统写入的坐标往往基于相机坐标系的标定结果，必须确认视觉输出的坐标是在哪个坐标系下表达的。一般视觉标定会直接映射到机器人USER坐标系，但仍然建议在程序中加一个“坐标合理性判断”，比如目标点离基准点超过一定范围就报警暂停。不要盲目相信视觉输出的每一个数。

3. 坐标系转换的底层逻辑与手写模板

3.1 为什么要自己写坐标系转换

有人会问：FANUC不是有自带的坐标系换算功能吗？为什么还要手写？

原因有两个。第一，系统自带的坐标系转换功能（比如通过偏移指令OFFSET）只能做固定方向的平移，涉及到工具姿态变化、坐标系旋转时不够用。第二，很多高级应用里，你需要在自己定义的坐标系之间变换，系统没有现成的按钮，只能通过程序实现。

举个例子，机器人要在一个倾斜的平面上码放工件，码放方向是斜的。如果你用全局坐标系一个个示教点，费时费力，而且一旦工件位置微调，所有点都要重新示教。正确做法是：在斜面建立用户坐标系UF，然后在UF内部按行列偏移计算位置，这样只需示教一个基准点，其他全部程序生成。

3.2 转换的数学原理：旋转矩阵+平移向量

坐标系转换的核心是旋转矩阵R和平移向量T。假设空间有一个点P，它在坐标系A中的坐标是PA，想得到它在坐标系B中的坐标PB，换算关系是：

PB = R_AB * PA + T_AB

这里R_AB是从A系到B系的旋转矩阵，T_AB是B系原点在A系中的坐标。

在FANUC的PR数据里，W、P、R三个欧拉角本质上就是在描述这个旋转矩阵R，而X、Y、Z就是平移向量T。所以坐标系转换问题的本质，就是根据两个坐标系的相对位姿关系，算出R和T，然后作用于目标点。

FANUC系统内部其实提供了完整的矩阵运算能力，通过用户宏程序里的矩阵变量M[i]来实现。但在TP程序里直接操作矩阵比较繁琐，我更推荐用KAREL程序处理复杂转换，TP里只做简单的加减法偏移。

3.3 手写模板：从A系转到B系

这里分享一个我实际项目里一直在用的KAREL参考程序骨架，作用是把一个PR[i]的点从用户坐标系A换算到用户坐标系B：

PROGRAM CONVERT_FRAME VAR source_point : POSITION result_point : POSITION frameA, frameB : FRAME rel_transform : FRAME temppos : XYZWPR BEGIN -- 读取两个用户坐标系的位姿 GET_UFRAME(frameA, 1) GET_UFRAME(frameB, 2) -- 读取源点（例如PR[1]） source_point = GET_POS_REG(1) -- 计算从A到B的相对变换 rel_transform = INVERSE(frameB) * frameA -- 应用变换 result_point = rel_transform * source_point -- 写入PR[2] SET_POS_REG(2, result_point) END CONVERT_FRAME

核心就是先取两个坐标系的相对变换矩阵，然后用矩阵乘法把点从A系映射到B系。这个模板可以套用在几乎所有坐标系转换场景：工件偏移、多工位镜像、不同夹具间的位置换算等。

如果只能写TP程序，一个替代方案是利用FANUC的“位置寄存器偏移”功能间接实现，但灵活性差很多。原则上建议：简单平移偏移用TP，复杂旋转转换上KAREL。

3.4 工具坐标系也对位置变量有影响

很多人只关注用户坐标系，忽略了工具坐标系UT对PR[i]的影响。实际上LPOS的X、Y、Z、W、P、R值，都是“工具末端在什么姿态、什么位置”的完整描述，而工具末端的定义就取决于UT。

同一个物理点，用UT[1]表示和用UT[2]表示，得到的LPOS值完全不同。所以项目里要形成铁律：所有涉及PR[i]的程序，必须明确标注“此PR基于哪个UT、哪个UF”，最好直接在程序注释里写清楚。我见过最离谱的事故，是一个工装的工具坐标系参数输错，导致视觉引导的所有点位全部偏移，排查了整整三天。

4. 实战案例：视觉引导下的动态码盘偏移

4.1 场景描述与工艺需求

项目是一个流水线上的视觉引导分拣码盘工位。视觉相机安装在固定位置，检测传送带上的工件位置，通过视觉通讯把工件的XY坐标偏差和旋转角度发给机器人。机器人需要从传送带上抓取工件，放置到托盘上，每层放4个，共3层。

基本要求是：抓取点随视觉结果动态变化，放置点在托盘固定位置，但要求根据来料角度的不同，机器人末端在放置前自动旋转相应的角度。同时托盘相对机器人基座的安装位置有偏差，需要通过一次标定把托盘坐标系实际定位出来。

4.2 坐标系拆分与PR规划

我先拆清楚了系统里需要的坐标系：

• UF[1]：机器人基坐标系（默认）
• UF[2]：视觉标定坐标系，也就是视觉结果直接映射后的坐标系
• UF[3]：托盘坐标系，基准点在托盘角点，X轴沿托盘长边

PR寄存器分配如下：

• PR[1]：视觉相机识别到的抓取点，由视觉写入
• PR[2]：抓取点经过工具/坐标系转换后的实际机器人目标
• PR[3]：托盘放置基准点（示教一次）
• PR[4]：当前位置换算到托盘坐标系后的临时值
• PR[10]~PR[12]：码放位置运算中间量

这个分配逻辑是：抓取链路用PR[1]→PR[2]，放置链路用PR[3]为基准动态生成PR[4]并调用运动。

4.3 抓取链路实现

视觉写入PR[1]后，程序先做坐标系修正：

! 视觉坐标系转机器人基坐标系 CALL VISION_TRANSFORM

这个CALL里的核心逻辑，就是我3.3部分的KAREL程序。视觉系统输出的是UF[2]下的坐标，机器人需要的是UF[1]下的坐标。如果不转换，直接拿视觉的X、Y去运动，由于相机安装角度和机器人基座有偏角，机器人跑过去会偏出几十毫米。

转换完成后，PR[2]就是机器人基坐标系下的实际抓取点。运动指令：

J P[1] 100% FINE L PR[2] 500mm/s FINE

这里有个小技巧：先J到P[1]安全点，再线性运动到PR[2]，避免刀具和传送带干涉。实际调试中，这个安全点的高度选择很关键，要高于工件最高点，同时不能碰到相机支架。

4.4 放置链路实现：托盘坐标驱动

托盘坐标系UF[3]标定完成后，所有码放位置都基于UF[3]生成。托盘每格的中心位置在UF[3]下的坐标是固定的，我可以直接写死在程序里，只需要考虑每层的Z高度变化。

! 第2层第3格位置 PR[4] = PR[3] PR[4, 1] = PR[3, 1] + 150 ! X方向偏移 PR[4, 2] = PR[3, 2] + 300 ! Y方向偏移 PR[4, 3] = PR[3, 3] + 80 ! Z方向抬升到第2层 PR[4, 4] = PR[3, 4] ! W角不变 PR[4, 5] = PR[3, 5] + 45 ! P角根据来料旋转

这里容易踩坑的地方是：直接修改PR[4]的X、Y、Z、W、P、R分量后，它只是LPOS被改了，JPOS不会自动更新。执行L指令运动时，由于L指令是笛卡尔空间运动，系统会实时逆解计算关节角，所以用L指令没问题。但如果你用J指令去PR[4]，系统读的是旧的JPOS，位置就会错。

所以在这个项目里，放盘全部用L指令，明确禁止使用J指令。程序开头加了一个判断：

IF R[20] = 1 JMP LBL[10]

R[20]是模式选择开关，如果处于“放置模式”，强制走L指令逻辑。这不是多此一举，是血的教训换来的。

4.5 视觉角度补偿的细节处理

视觉系统除了XY坐标，还会反馈一个来料旋转角A。这个角度要在放置路径中补偿，否则工件放下去是歪的。

补偿逻辑是这样实现的：先把PR[2]的坐标复制到临时PR[10]，然后修改PR[10]的W分量（或P、R，取决于工件是水平旋转还是俯仰旋转）：

PR[10] = PR[2] PR[10, 4] = PR[10, 4] + R[30] ! R[30]是视觉反馈的角度

注意这里修改的是第4个分量，也就是W角。对于水平放置的工件，Z轴旋转就是W角。改完之后，先L到PR[10]正上方，再下移到PR[2]抓取。

这里有一个姿态插补的坑：当起始姿态和结束姿态差异较大时，L指令的姿态过渡可能不是最短路径，会出现机器人“绕远路”的现象。特别是W角从接近0度突然变到接近180度时，机器人会大幅回转，看起来很吓人。解决办法是在路径中加中间点，先让姿态转到一半，再继续下探。或者用FANUC的姿态插补方式切换指令。

4.6 整体程序的异常分支处理

实际运行中，视觉可能是超时、误检、识别出界外点等异常。我在主循环里加了分支：

IF R[20] = 0 JMP LBL[100] ! 视觉无结果，跳过抓取 IF DI[5] = ON JMP LBL[200] ! 托盘满，切换

另外，每个PR在作为目标点运动前，我都加了一个坐标范围检查：

IF PR[2, 1] > 1000 THEN CALL ALARM_PAUSE ENDIF

这个范围的上下限，以机器人工作空间和传送带相机覆盖范围为准。视觉偶尔会报出一个离谱的坐标，如果不做检查，机器人会直接冲过去——轻则撞夹具，重则撞相机支架。宁可误报多停几次，也不能让没验证的点直接进运动指令。

5. 常见问题与排查

我把做PR相关调试这些年遇到的高频问题整理成一个速查表，很多问题都不是语法错误，而是逻辑和坐标系的问题，排查起来非常费时间。

5.1 程序内修改PR后位置不更新

这个问题的本质，就是前面反复强调的LPOS和JPOS不同步。直接对PR[i, n]赋值，或者对PR[i]做加减运算，系统并不会自动重算另一种表达方式。解决思路有两个：

一是处理完后用重算指令强制同步。KAREL里可以用：

rel_point = GET_POS_REG(i) SET_POS_REG(i, rel_point)

这样会触发系统重新计算JPOS。

二是在运动指令层面规避，只使用L类指令，不用J类指令。L指令按笛卡尔坐标执行运动，每次都会实时逆解，所以LPOS正确即可。

5.2 坐标系混淆导致的“幽灵偏移”

这类问题最难排查，因为程序语法完全正确，PR数值看着也对，但机器人就是不在预期位置。排查思路是：

1. 先确认运动指令里指定的是什么UT/UF。比如L PR[5]后面跟了UT:3, UF:4，但PR[5]当初写入时用的是UT:1, UF:1，那结果必然错。
2. 检查手动示教时页面顶部的UF/UT显示状态。
3. 检查视觉或上位机写入PR时基于哪个坐标系。

一个比较彻底的预防方案，是在项目程序开头把所有涉及到的坐标系全部显式初始化一遍：

UFRAME_NUM = 1 UTOOL_NUM = 1

这样至少保证程序启动时坐标系是确定的，不会受示教器残留状态影响。

5.3 PR数值超出范围

FANUC位置寄存器的数值范围有限制。如果写入的坐标值过大，或者角度值超出正常范围，有些版本的系统会表现为PR值变为“########”溢出显示，程序运行会报错。

这种情况经常出现在视觉给出异常值时。所以前面说的坐标范围检查，不只是防撞机，也能防止数据溢出导致系统崩溃。

5.4 断电后再上电PR被重置

老旧一些的FANUC机型，PR寄存器有部分存储区域在断电后不保持。需要确认PR[i]是否被分配到保持型存储区。通常控制柜内的主板电池保证SRAM不掉电，但电池耗尽或更换时可能导致数据丢失。

重要点位和标定数据不能只存在PR里，必须定期备份或者写在一个自动执行的$MORGRP初始化程序里，每次上电自动写入。这个习惯能避免很多“早上开机点位全丢了”的抓狂现场。

6. 一点个人体会

位置变量PR[i]在FANUC系统里，看着就是个简单的数据存储，真正让它有威力的，是你对坐标系的掌控能力。我接触过不少调试工程师，PR指令背得很熟，但一到坐标系转换就发怵，看到WPR角度就头大。其实坐标系转换没有想象的那么玄，核心就是先搞明白“这个点是谁在什么坐标系下观察到的”，再找到两个坐标系之间的相对位姿关系，剩下就是矩阵乘法的功夫。

我建议刚入门的朋友，不要急着抄现成模板，先花一个下午在机器人旁边做一次坐标变换实验：示教几个点、手动改改UF的旋转角度，亲眼看看X、Y、Z、W、P、R是怎么变化的。这个感性认识，比看十遍手册都管用。等你真正理解了“所有位置都是相对的”这句话，PR[i]基本就能随心所欲了。