FANUC机器人RSR/PNS远程启动详解：原理、配置与PLC联调实战

1. RSR和PNS到底是什么，为什么做自动化线绕不开

接触FANUC机器人这套设备的人，应该都见过RSR和PNS这两个缩写。做过自动化线改造的电气工程师尤其绕不开：流水线上换产品、变节拍、切配方，总不能每次都让人拿着示教器去选程序按启动，产线要的是PLC一个信号过去，机器人自己选对程序、自己开始干活。RSR（Robot Start Request）和PNS（Program Number Select）就是干这个的。

但很多刚接触的人搞不清两者到底有什么区别。手册上写得都很官方，一个叫“机器人启动请求”，一个叫“程序号选择”。看起来都像“PLC告诉机器人跑几号程序”，实际上两者的信号定义、握手方式、使用场景差别挺大，而且一旦用错，现场调试能折腾你一天。

我建议所有做产线集成、机器人调试、设备维护的工程师都把这套东西摸透。原因很简单：现在工厂上位机联机器人，十有八九走的是现场总线（Profinet、EtherNet/IP、DeviceNet），而机器人侧的远程启动方式，最常用的就是RSR和PNS。你不懂它，后面出了问题连报警都看不懂。

1.1 RSR和PNS不是硬件，而是一套“遥控启动协议”

先说清楚一个容易误解的地方：RSR和PNS不是额外的硬件模块，也不是什么特殊总线协议，它们本质上是FANUC控制器内部预先定义好的一组UOP信号（Universal Operator Panel，即通用操作面板）。你可以把UOP理解成机器人控制器自带的一套“遥控器按钮”，主机PLC通过IO或者现场总线去按这些按钮，机器人就知道该干什么了。

比如RSR方式，PLC要做的事情很简单：把要运行的程序号用二进制形式放到RSR1到RSR5这几位信号上，等机器人准备好之后，给RSR_STRT一个启动脉冲，机器人就照着程序号去查“程序号映射表”，找到对应程序并开始执行。整个过程不需要示教器，也不需要人工参与，完全由产线逻辑控制。

PNS方式逻辑上也类似，区别在于它使用的是PNS1到PNS8用于程序号，同时使能、启动、保持、复位等信号分得更细。如果你做过DCS或者SIS系统，可以把它理解为“带确认机制的选择指令”——机器人收到程序号后，是否选择成功、是否正在运行、是否结束，都有对应的状态反馈给PLC。这样上位机每一步都能跟踪到机器人的状态，而不是信号发出去了就撒手不管。

1.2 什么时候用RSR，什么时候用PNS

很多人问：既然都能远程启动程序，那我到底该用哪个？我的经验是，看你的工艺节拍和上位机联锁的复杂程度。

RSR偏向“请求型”，主机给一个程序号，给一个启动脉冲，机器人就开始跑。它信号少、时序简单，特别适合节拍快、程序数量不算多、上位机只要“你跑吧，跑完告诉我”这种场景。比如机器人上下料站，就一个装夹程序一个卸件程序，我用RSR非常顺手，PLC不用关心机器人内部怎么选程序，只要保证启动时序正确就行。

PNS偏向“选择型”，它把“选程序”和“启动程序”拆开，多了使能、确认、保持、复位等交互信号。适合程序数量比较多、上位机需要精确知道当前选的是哪个程序、甚至需要中途暂停复位的场景。比如一个机器人要服务多条输送线，十几套程序来回切，还要求每次开工前向上位机上报当前程序号，用PNS做起来更清晰。

下面这个表是我自己做项目时习惯用的对比，具体信号数量以你控制器里实际出现的UOP定义为准：

一句话总结：简单方案用RSR，复杂联锁用PNS。两种都能让你把示教器扔一边，但选错了，后面写PLC状态机的时候会非常难受。

2. 原理拆解：程序号映射、UOP信号、总线通信怎么配合

说到底，RSR和PNS能跑起来，靠的是三样东西配合：程序号映射表、UOP信号、现场总线数据区。这三样里有一条没对，机器人就理都不理你。

2.1 核心是程序号映射表，而不是信号本身

新手最容易踩的坑就是把RSR/PNS当成“直接指定程序名”的功能。实际上，总线信号里传的只是数字，比如5，机器人并不知道5代表哪个TP程序。它需要去查一张表，这张表一般叫Program Number Mapping，翻译成“程序号对应表”或者“RSR/PNS设定画面”。你在这张表里把数字和程序名绑好：

当PLC发来程序号3，控制器就去找名为PALLETIZE_A的TP程序并启动它。如果表里没有3这个编号，或者3对应的程序名写错了，机器人会直接报警，最常见的报警就是“Program not found”或者“Invalid RSR program”。

这里有个实操经验：程序号映射表里空余的编号建议全部清空或者填成无效程序，别随便留一些不存在的名字。我见过有人为了省事把所有编号都填成同一个程序，结果PLC发错号时机器人也照样启动，跑到一半才发现程序不对，整条线都停下来返工。这张表一定要当成正式配置来管理，改一次就要做一次版本记录。

2.2 UOP信号是机器人的“遥控面板”

UOP信号分两类：一类是PLC发给机器人的输入信号，在控制器里叫UI（User Input），另一类是机器人反馈给PLC的输出信号，叫UO（User Output）。RSR和PNS的启动、使能、保持等信号，其实就是一组定义好的UI信号。

为什么说它像遥控器？因为你按遥控器上的“频道数字”，电视就换台；按“电源”，电视就开关。UOP就是把机器人这些可被远程控制的动作，全部固化成信号点，PLC总线上对着一顿操作，机器人就执行了。你可以把UI信号映射到物理数字量输入模块上，也可以映射到现场总线的输入数据区里。

比较关键的信号，以RSR为例，大致是这些：

• RSR1~RSR5：程序号的二进制编码位，位权和普通二进制一样，1、2、4、8、16。
• RSR_ENBL：RSR功能使能，只有在ON状态下，后续启动请求才会被接受。
• RSR_STRT：启动请求脉冲，上升沿有效。
• RSR_HOLD：暂停请求，适合程序执行中途让机器人暂停。
• RSR_FAULT：和故障复位相关的信号，不同版本位置不太一样。

PNS那边也类似，只是把RSR前缀换成PNS。具体哪些信号配置在哪个地址，以你控制器【I/O】-【UOP】画面里实际显示为准，不同版本、不同软件选项会有差异。

2.3 从现场总线到UOP的信号链路

搞懂信号链路，排查问题就快多了。现代项目里PLC一般通过Profinet或者EtherNet/IP连接FANUC机器人。链路大致是：

PLC数据区 → 总线IO从站 → 机器人控制器总线接口 → 内部映射 → UOP信号 → RSRS/PNS逻辑 → 程序号映射表 → TP程序启动。

这条链路上任何一环断了，问题表现可能完全一样：机器人没反应。比如Profinet组态里IO长度不对，数据根本没传进来；或者UOP映射画面里RSR_ENBL没有绑到对应的输入字节上；又或者总线数据明明变了，但机器人侧信号量没有刷新。这些你光看PLC程序是看不出来的，必须连到机器人【I/O】画面里看当前信号值到底有没有变化。

2.4 启动条件：AUTO模式、使能、安全链

RSR/PNS要生效，还有个前提条件：机器人必须处于AUTO模式，也就是示教器钥匙开关旋到AUTO档。如果你用T1或T2档，远程启动功能通常会被禁止。这个看似入门级的问题，我现场遇到过好几次，一群人围着PLC查半天，最后发现钥匙还在T1档。

另外，机器人还有自己的安全链和命令使能。通常上位机需要先看到机器人输出的某个“远程就绪”或者“命令使能”信号为ON，才能发启动请求。这个信号名称可能在UO里叫CMD_ENBL，也可能叫REMOTE_READY，不同配置不一样。稳妥的做法是：PLC侧把“机器人准备完成”作为启动的必要条件，不要图省事直接发RSR_STRT。

3. 实战配置：从R-30iB设置到PLC侧时序实现

讲完原理，来看一遍完整配置流程。这里以一台R-30iB控制器、Profinet接线的常见组合为例，菜单名称不同版本略有差异，但思路通用。

3.1 机器人侧五步配置

第一步，确认总线通信。接入Profinet之后，先在【MENU】-【I/O】里确认Profinet模块在线，数据的输入输出尺寸和PLC组态一致。这一步经常被忽略，实际上很多“信号没反应”的问题就是IO长度对不上，数据错位。

第二步，映射UOP信号。进入【MENU】-【I/O】-【UOP】画面，把UI输入信号里的RSR1、RSR2、RSR3、RSR4、RSR5、RSR_ENBL、RSR_STRT分别绑到当前Profinet输入区的具体位。注意绑定时看清方向：PLC发给机器人的数据，对应的是机器人的UI输入；机器人发给PLC的状态，对应UO输出。

第三步，选择程序选择方式。进入【MENU】-【SYSTEM】-【Config】画面，找“Program Select”或“Remote Program Select”之类的选项，把它改成RSR或者PNS。有的系统里这个选项翻译成“程序选择方式”，可选项有RSR、PNS、BCD，选成对应的就行。

第四步，维护程序号映射表。进入【MENU】-【SETUP】-【RSR/PNS】画面，把程序号和程序名一一填好。这里要注意程序名必须和TP程序里的名称完全一致，大小写、空格都不能错。

第五步，保存并重启。改完上述配置后，建议做一次冷启动，确认修改真正生效。我在系统里改完后不敢确定，就用Roboguide先模拟一遍，确认无误后再到现场设备上操作。

3.2 PLC侧程序号编码与启动脉冲

机器人侧配置好后，PLC侧的核心工作就是把任务号编码到RSR位，并按正确时序给出启动脉冲。下面是一段很典型的ST语言写法，CODESYS和S7-SCL稍微改一下就能用：

// 1. 程序号编码：把0到31的任务号拆到RSR1~RSR5 bRSR1 := (iTaskNo AND 16#01) <> 0; bRSR2 := (iTaskNo AND 16#02) <> 0; bRSR3 := (iTaskNo AND 16#04) <> 0; bRSR4 := (iTaskNo AND 16#08) <> 0; bRSR5 := (iTaskNo AND 16#10) <> 0; // 2. 使能信号：机器人给出命令使能时置ON bRSR_ENBL := bCmdEnable; // 3. 启动脉冲：上升沿触发，保持100ms后复位 bRise := bStartCmd AND NOT bStartOld; bStartOld := bStartCmd; IF bRise THEN bRunTimer := TRUE; END_IF; stTimer(IN := bRunTimer, PT := T#100MS); IF bRunTimer AND NOT stTimer.Q THEN bRSR_STRT := TRUE; ELSE bRSR_STRT := FALSE; END_IF; IF stTimer.Q THEN bRunTimer := FALSE; END_IF;

关键在于启动脉冲不能太短。RSR_STRT至少要保证机器人侧能采到上升沿，现场我用的是100ms，一般足够。有的PLC扫描周期只有几毫秒，但你不知道机器人那边任务调度是多久，脉冲给太短，可能导致机器人某几个扫描周期没看到信号，启动指令就丢了。

3.3 启动时序里的竞态问题

比编码本身更隐蔽的是“程序号还没稳定，启动脉冲就来了”这种竞态。想象一下：RSR1到RSR5是同一个字节里的5个位，PLC扫描周期内如果程序号变了，而这5个位不是同一瞬间刷新到总线上，中间就有可能闪现一个中间态。比如任务号从3变成4，RSR1这个位从1变0，RSR2从1变0，RSR3从0变1，如果三条信号线上跳变时间差了几毫秒，机器人可能看到的是5或者7。

解决思路是“先稳定，再启动”。PLC侧务必先把程序号编码输出，等一段时间（比如20到50ms），确认总线数据稳定后，再给出RSR_STRT脉冲。如果你的系统支持，也可以把启动使能信号RSR_ENBL当成“选通信号”：程序号变化期间RSR_ENBL保持OFF，等程序号稳定后再把RSR_ENBL置ON，再发启动脉冲。这样即使中间出现短暂乱码，也因为是禁止状态而被机器人忽略。

4. 场景落地：上下料工站的状态机设计

配置会了，但真正难的是把它编进产线程序里。下面用一个我常做的上下料工站来演示，怎么用状态机思路把RSR接入工艺逻辑。

4.1 一条产线怎么用RSR切换多个程序

假设这台FANUC机器人负责两台CNC上下料，产品有两个型号A和B，每种型号有各自的抓取位置、放置位置和放料方式，对应机器人侧四个程序：LOAD_A、LOAD_B、UNLOAD_A、UNLOAD_B。

上位机PLC拿到订单或者工件扫码结果，就知道当前该用哪套程序，比如来了一个A型号工件，上位机把任务号1发给机器人，对应LOAD_A。如果A工序干完该下料了，上位机再发任务号2，对应UNLOAD_A。实际PLC侧的状态机可以这样写：

空闲状态收到“新任务请求”后，先检查机器人是否空闲，也就是UO里的BUSY信号是否为OFF，同时CMD_ENBL是否为ON。条件满足后，把任务号写入编码变量，并启动20毫秒稳定延时。延时结束，置位RSR_STRT输出，同时启动100毫秒的启动脉冲定时器，定时到后复位RSR_STRT。

然后PLC进入“运行等待”状态，盯着机器人的BUSY信号和DONE信号。BUSY从OFF变ON，代表机器人已经接受任务开始跑；BUSY从ON变OFF，代表程序结束。DONE信号则能区分“正常跑完”和“中途报警”。如果机器人报了故障，PLC要进入故障处理状态，先看报警代码，处理好后给机器人发故障复位信号，再根据情况决定是否重新启动任务。

4.2 用PNS做程序号确认和联动扩展

如果这个工站要求上位的MES系统记录每次实际执行的程序，推荐用PNS取代RSR。原因在于PNS可以把“程序选择成功”作为一个明确的中间状态回给PLC。比如PLC先发PNS1~PNS8和PNS_STRT，机器人检查程序号映射表没问题后，会反馈一个“程序已选择”状态；PLC收到这个状态后，再执行真正的启动动作。两段式握手比RSR的“闷头跑”可追踪性强很多。

这也是我在项目里给大家的建议：只要甲方对设备状态追溯有要求，直接上PNS。因为RSR的反馈信息更间接，你得靠BUSY和DONE去猜，而PNS让PLC每一拍都知道机器人卡在哪一步，日志也好写，联调也好说话。

4.3 用宏变量和寄存器做配方切换

另一个和RSR/PNS配合得很好的思路，是让程序号只决定“入口程序”，内部逻辑靠寄存器变量切换。写过FANUC宏程序的朋友应该马上能反应过来：如果你写过#1-1 GE 0这类分支判断，就知道变量决定走向有多灵活。

比如我为一条产线做了五个工位，每个工位加工参数不一样。机器人侧只写了一个通用程序MAIN，里面根据寄存器R[100]的值选择不同的偏移量、速度和计数值。PLC那边用RSR启动MAIN时，任务号永远填1，同时把R[100]写成当前工位号。这样做的好处是：新增一个工位不需要在机器人里新建程序，只要改改PLC配方表，把新的工艺参数写入寄存器，再配一个任务号就行。程序号映射表维护成本极低，后期扩展很舒服。

5. 常见问题与排查技巧实录

最后把我在现场踩过、见过的问题整理一下，基本都是RRS/PNS联调时的高频故障，按这个顺序排查会快很多。

5.1 程序没启动：先查这五处

我自己习惯先看机器人【I/O】-【UOP】画面，手动触发一次RSR_STRT，看信号值有没有变化。如果画面里信号值变了但机器人不动，问题大概率在映射表或机器人侧逻辑；如果画面里信号值根本没变化，问题就在总线通信和IO映射上，跟机器人半毛钱关系没有。

5.2 程序号偶尔错乱

这种问题最阴间。平时跑得好好的，偶尔一次跑到错误程序上去，或者明明发的是2号程序，机器人却执行了4号程序。大概率是程序号位不稳定造成的竞态。我遇到最典型的一次，是PLC把任务号存在一个Word里，然后分两条MOVE指令依次传送给两个不同IO模块，结果两条指令之间夹了一个中断，RSR信号出现了一个短暂的中间态，机器人就抓着这个错误编号启动了。

解决办法就是前面说的“先稳定再启动”：程序号编码输出之后，至少延时一个总线刷新周期再加启动脉冲。如果产品对安全和防错要求高，最好增加程序号回读校验——把机器人实际执行的程序号通过UO输出反馈给PLC，PLC在启动前和启动后各读一次，不一致就报错停机。

5.3 结合输送线跟踪（Line Tracking）时要注意什么

现在很多项目里机器人要跟着输送线走，也就是常说的Line Tracking，中文有的叫输送线跟踪或者飞拍跟踪。这种场景下RSR/PNS同样可以用来远程启动跟踪程序，但要注意：RSR/PNS只管“启动哪个程序”，不做任何路径生成。机器人能跟上输送线，靠的是编码器反馈跟踪速度和位置，以及TP内部对跟踪数据点的处理。

实战中我一般这样设计：PLC通过RSR启动带跟踪功能的程序，同时把当前工件的工艺信息、输送线速度、到达位置等参数写入寄存器或总线数据区。机器人一收到RSR_STRT，先读取这些参数，再开始跟踪动作。如果程序启动得比输送线上工件到达的时机早或晚，跟踪结果就会偏差，所以PLC发启动脉冲的时序要和输送线位置信号严格联动，不能只看机器人空闲信号。

还有个细节：跟踪模式下尽量不要中途用RSR_HOLD暂停，因为机器人暂停期间输送线可能还在走，位置关系会错位。如果一定要中途停下，需要先让机器人退出跟踪模式，或者给输送线也发一个暂停命令，两边同步停才安全。

5.4 Roboguide离线调试能省一半时间

RSR/PNS的调试最怕现场边改边试，每改一次映射表都要重启控制器，极其浪费时间。我现在做项目都会先在ROBOGUIDE里把机器人控制器虚拟出来，配合虚拟PLC或者IO信号模拟器，把RSR/PNS的启停时序完整跑通一遍。

ROBOGUIDE的好处是能直接看到UOP信号的状态变化，还能人为制造一些极端情况，比如启动脉冲只给50ms、程序号映射表故意漏一项，都能在虚拟环境里提前发现。把这些坑在离线阶段踩完，现场联调基本就是一次过。这点对做机器人集成项目的人来说，真的是能救命的工作习惯。

就拿RSR/PNS来说，我的做法是先在ROBOGUIDE里把映射表、UOP映射、启动时序全部配好，导出配置清单，然后再到机器人上照着录入。现场如果还有偏差，再对照我前面说的排查顺序，把信号链路逐段确认一遍。这套流程走下来，踩过的坑基本都能变成可以复用的经验。