简介FANUC机器人自动运行PNS设置指导手册是一份面向工业自动化工程师、现场调试及维护人员的实操型技术文档重点解决生产线上多任务快速切换与无人化自动运行问题。资源包为单个docx文件大小约1.61MB内容涵盖PNS概述、参数设置步骤、典型应用场景、故障排查及培训维护等完整章节。文档从登录系统、创建程序、设置参数如3100号到启动PNS逐步展开并结合多品种小批量生产、流水线作业、物料搬运等常见场景进行说明便于读者直接对照操作。同时手册还针对参数错配、通信异常、程序报警等给出了排查思路和安全注意事项能够帮助使用者减少调试时间、规避现场风险。已有977人学习下载适合需要快速掌握FANUC PNS配置或用于内部培训的技术人员参考。 干这行时间久了你会碰到一个特别典型的场景产线换型PLC那边噼里啪啦切了一堆信号机器人这边还得人工跑到示教器上选程序、按启动。小批量多品种的产线尤其痛苦一天换十几次型光来回跑就能跑断腿。FANUC的PNS功能Program Number Select程序号选择就是专门解决这个问题的——通过外部PLC的8根信号线远程选择机器人运行的TP程序并自动启动最多覆盖255个程序号。这篇文章是我结合现场调试经验整理的一份PNS设置指导从原理、配置、调试到常见坑一次说清。适合正在做FANUC机器人产线集成的工程师、现场设备维护人员以及准备用PNS做远程启动但还没摸清门道的人。1. PNS到底是什么——换产频繁的产线为什么需要它1.1 自动运行的几种方式FANUC机器人实现外部自动运行最基础的方案是“CYCLE START 固定程序”。也就是说PLC给一个启动信号机器人就运行当前示教器上选中的那个程序。这个方案的问题很明显换产品就得人去选程序根本做不到全自动换型。再往上走FANUC提供了RSRRobot Service Request和PNSProgram Number Select两种外部程序选择功能。RSR的做法是在系统里预设最多8个程序外部通过3位二进制信号选其中一个启动。PNS则是把程序选择的范围扩大到了255个用8位二进制信号直接指定程序号。PNS的本质就是把“选哪个程序”这件事从人手操作交给PLC逻辑去决定。RSR和PNS的区别说白了就是“8选1”和“255选1”的区别。8个程序对大多数单机工作站够用但遇到多车型共线、上百种产品配方的情况RSR就捉襟见肘了。PNS还多了一个好处——程序号本身就携带了产品信息PLC的工程师可以直接把产品编码映射到PNS信号上逻辑链路更短出问题也好排查。1.2 PNS的工作时序理解PNS关键是理解它的信号时序。整个工作过程可以拆成四步PLC把目标程序号换算成8位二进制输出到PNS1~PNS8信号上。PLC等这些信号稳定后发出一个PNSTROBE选通脉冲相当于告诉机器人“程序号已经准备好了请锁存”。机器人控制器收到选通脉冲锁存程序号检查该编号的TP程序是否存在然后自动启动这个程序。程序执行完毕机器人通过输出信号通知PLC“本次任务完成”PLC收到后才能开始下一轮程序号下发。这个时序里最要命的就是第二步。如果PLC的程序号还没稳定就发选通脉冲机器人锁存到的可能是一个中间态的错误程序号结果就是机器人跑了个错程序。后面我会专门讲这个坑。2. 动手之前选项、系统变量与信号清单2.1 先确认控制装置有没有PNS选项PNS不是所有FANUC机器人默认就有的功能它是一个可选功能包。你在配置之前第一件事是确认当前控制装置R-30iA、R-30iB Mate等都适用是否已经激活了PNS选项。确认方法有两个按下【MENU】→【系统】→【版本】或者【选项】页面在列表里找有没有“PNS”相关的选项名。有的版本显示为“Program Number Select”。在系统变量里搜$PNS_SELECT如果这个变量存在说明系统支持PNS如果完全搜不到基本可以断定PNS选项没激活。顺带提醒一句FANUC还有一款仿真软件叫Roboguide早期叫NCGuide上面新建控制器时也能勾选PNS选项。我强烈建议你先把配置在仿真环境里跑通再上真机后面会讲具体怎么做。2.2 系统变量$PNS_SELECTPNS功能的总开关是系统变量$PNS_SELECT。把这个变量设为1即启用PNS外部启动模式。你可以在【MENU】→【系统】→【变量】页面里找到它也可以直接在KAREL程序里读写。这里有个容易混的点RSR和PNS是两种互斥的启动模式。如果你的控制器已经配过了RSR想改用PNS别忘了把RSR相关的使能变量复位否则会出现外部启动信号发过去但机器人不响应的怪现象。2.3 信号清单与UI/UO映射PNS依赖UOPUser Operator Panel信号体系。UOP是FANUC定义的一套标准信号集合UI是输入UO是输出每个信号都有固定的功能含义。PNS相关的核心信号如下信号名对应UOP信号功能说明PNS1UI[9]程序号第1位权重1PNS2UI[10]程序号第2位权重2PNS4UI[11]程序号第3位权重4PNS8UI[12]程序号第4位权重8PNS16UI[13]程序号第5位权重16PNS32UI[14]程序号第6位权重32PNS64UI[15]程序号第7位权重64PNS128UI[16]程序号第8位权重128PNSTROBEUI[17]程序号选通脉冲PNSREQUI[18]程序号请求信号程序号的计算方法很直接把导通的PNS信号对应权重加起来。比如要选程序号5就导通PNS1权重1和PNS4权重4145。要选程序号200就是PNS128 PNS64 PNS8128648200。注意这里不是顺序编号是二进制权重编码排查时一定要按权重逐位核对。PNSREQ这个信号在部分版本里叫PNS请求可以理解为PLC告诉机器人“我准备要下发程序号了请做好准备”。有的现场图省事不用PNSREQ只用PNSTROBE触发程序选择也能跑但严格按标准时序来稳定性会好很多。2.4 I/O映射这一步不能省UOP信号是控制器内部的概念要和外部PLC通信必须把UI/UO信号映射到实际的物理I/O或者网络I/O上。比如你的PLC通过EtherNet/IP和机器人通信那就要在机器人的I/O配置界面里把UI[9]映射到EtherNet/IP模块的Input Tag第0位把UI[17]映射到对应位以此类推。具体路径一般是【MENU】→【I/O】→【UOP】→【配置】进去后逐个配置UI/UO信号对应的物理地址。不同控制柜和通信协议的操作界面略有差异但思路是一致的把PNS这一组信号完整映射到PLC能读写的地址上。映射完成后建议先做一件事在机器人I/O监视界面手动强制PLC侧的对应位确认机器人侧能正确收到。这一步能过滤掉一大半“线没接通”“地址配错”的低级问题。3. 核心配置把PNS跑通的完整步骤3.1 启用PNS并设置好信号映射第一步把$PNS_SELECT设为1启用PNS模式。第二步按上一节的方法把UI[9]到UI[18]这组PNS信号映射到你的通信模块上。同时把UO状态信号也映射好至少要有两个一个“程序运行中”信号给PLC做联锁一个“程序完成”信号告诉PLC上一轮任务结束了。第三步把机器人切到AUTO模式。这是外部启动的前提条件PNS只能在AUTO模式下响应外部启动信号。T1/T2模式下PNS是不会动作的很多新手第一次调试时会在T1模式下试半天然后怀疑系统有问题。3.2 TP程序的组织方式PNS模式下的程序组织最简单、最不容易错的方案是约定的程序号直接作为TP程序的程序名。比如PLC发程序号5那就建一个名为“5”的TP程序PLC发程序号200就建一个名为“200”的TP程序。你没有听错程序名可以用纯数字。如果你们工厂的程序命名规范要求必须用字母开头比如“P200”、“WELD_01”那就要引入一个中间映射逻辑。做法是建一个固定程序名的总控程序比如叫“MAIN”然后在里面根据当前PNS程序号做分支跳转。总控程序里做分支可以用IF条件加CALL调用实现判断逻辑的核心是读取当前锁存的PNS程序号。FANUC不同版本的变量名有差异有的版本在TP里可以直接读到当前PNS编号有的需要借助KAREL程序读取后写入寄存器。不管用哪种最终都是一个逻辑程序号 1 → 调用 WELD_01 程序号 2 → 调用 WELD_02 程序号 3 → 调用 SPRAY_03我把这两种方案都实践过。程序号对应程序名简单粗暴适合程序数量不多、程序名可以由工程师自由定义的场景。总控分支的方式前期配置量大一点但程序命名规范、后期维护方便尤其适合上百个程序的场合。3.3 程序里别忘了CLR_PNSPNS模式里有一个TP指令特别容易遗漏叫CLR_PNS它的作用是清除PNS程序号选择状态。程序执行完后控制器不会自动清除PNS状态如果你下一个周期还发同样的程序号没有CLR_PNS的复位动作部分版本会出现启动信号虽然给了、但程序不重新运行的情况。标准做法是在每个PNS程序的末尾加上CLR_PNS指令。加了这条指令后控制器会复位内部的PNS选通状态同时向PLC发出一个“程序完成”的输出信号这样PLC才能确认“上一轮任务真正结束了可以发下一轮程序号”。一个典型的PNS程序结构大概是这样的1: J P[1] 50% FINE ; 2: LBL[1] ; 3: CALL WELD_MAIN ; 实际工艺调用 4: J P[2] 50% FINE ; 5: CLR_PNS ; 清除PNS选通状态如果你用的是“程序名编号”的方案那每个数字编号的程序末尾都要加这一句别漏。3.4 PLC端下发程序号的逻辑机器人端配置完成后轮到了PLC端。PLC的主要工作是把产品代码换算成8位PNS二进制信号按正确时序输出。这里给一段ST风格的伪代码方便理解时序(* 假设产品代码存储在变量 ProductCode *) (* 第一步输出程序号二进制信号 *) PNS1 : ProductCode.0; PNS2 : ProductCode.1; PNS4 : ProductCode.2; PNS8 : ProductCode.3; PNS16 : ProductCode.4; PNS32 : ProductCode.5; PNS64 : ProductCode.6; PNS128 : ProductCode.7; (* 第二步延时50ms等信号稳定 *) TON(IN : TRUE, PT : T#50MS); (* 第三步发选通脉冲 *) PNSTROBE : TRUE; TON(IN : TRUE, PT : T#200MS); PNSTROBE : FALSE;核心时序原则是先输出程序号延时稳定再发选通脉冲然后复位。程序号的稳定时间建议至少留50ms选通脉冲宽度建议100ms以上。有些工程师图省事程序号和选通脉冲同一扫描周期输出这在PLC扫描时间短、机器人扫描时间长的情况下很容易丢信号或者收到错误程序号。3.5 用Roboguide离线验证强烈建议所有人在真机调试前先用Roboguide或者NCGuide把PNS逻辑完整验证一遍。在Roboguide里新建控制装置时勾选PNS选项。然后按前面步骤配置$PNS_SELECT、映射UO/UI信号。Roboguide里有一个I/O仿真面板可以手动强制UI信号状态。你可以模拟PLC的时序一步步给PNS1~PNS8赋值再给PNSTROBE一个脉冲观察机器人是否按预期启动了对应编号的程序。这一步的成本极低但能帮你提前发现程序组织逻辑的问题。我曾经在仿真里发现单纯给PNSTROBE脉冲而PNSREQ没给的话机器人根本不会锁存程序号。这种问题如果在现场排查至少半天时间就进去了。4. 远程启动的调试与报警排查4.1 按下启动没反应从哪开始查最经典的现场问题PLC那边信号都给了程序号也发过去了机器人纹丝不动。我的排查习惯是下面这个顺序第一步确认机器人处于AUTO模式示教器上的运行状态没有报警、没有暂停。外部急停、安全门、防护围栏互锁信号任何一个没复位PNS都不会动作。第二步在机器人I/O监视界面看UI[9]~UI[18]的实时状态和PLC侧实际输出的信号逐位核对。这一步能快速判断是通信映射问题还是PLC逻辑问题。如果机器人侧信号和PLC侧不一致查通信模块的映射和字节序。第三步如果信号都对查$PNS_SELECT是否真的是1PNS选项是否激活。有的系统里$PNS_SELECT有多个取值有的版本是“0禁用、1启用PNS、2启用RSR”改错了会导致启动命令不生效。第四步看程序号对应的TP程序是否存在。PNS发程序号50但控制器里根本没有名为“50”的程序自然启动不了。排查方法是在示教器程序列表里确认一下。4.2 程序号不对、选错程序的坑比完全没反应更麻烦的是程序号发出了机器人也动了但跑的不是目标程序。这种问题十有八九出在信号映射或编码时序上。我举一个真实案例。现场PLC发程序号7机器人跑的是程序号3。逐位核查后发现PLC工程师把PNS信号的权重搞反了他把PNS1对应到了程序号的第3位PNS4对应到了第1位。7的二进制是00000111按错误映射换算过来控制器锁存到的就是123结果自然是错的。另有一起是字节序问题。用的是EtherNet/IP通信PLC侧的数据排列是高字节在前机器人侧配置没调整导致PNS8~PNS128这一组高权重信号全部错位。程序号超过7就乱套。这种问题最隐蔽排查时一定要逐位对照不要只看“有信号”就以为是对的还要看信号落到了哪一位上。还有一个常见原因PLC的程序号输出和PNSTROBE选通脉冲之间的稳定延时太短。特别是PLC用了立即刷新输出而机器人侧通信模块的刷新周期和PLC不同步程序号还没稳定选通就来了。这个我在前面已经强调过稳定时间至少留50ms。4.3 偶发性故障与时序干扰有时候不是每次都不行而是“十次里面坏一次”这种偶发问题最磨人。我的经验是只要程序号不对优先怀疑时序问题而不是先怀疑通信模块故障。排查思路是让PLC把每次下发的程序号、PNSTROBE时标、机器人侧实际接收到的信号状态全部记录下来出现问题后对比两边的时间戳。有条件的话可以在机器人侧用后台KAREL任务记录UO/UI状态变化再导出时间序列。很多偶发情况的根源是PLC程序其他网络对PNS输出字做了意外的改写。比如某段初始化程序在特定条件下把输出字清零了恰好和PNSTROBE的上升沿撞在一起。如果你在PLC端查不到问题就把PNS信号从普通输出字挪到专用的、没有其他程序读写的地址上。4.4 常见报警与根因对照报警/现象排查方向程序不存在类报警程序号对应TP程序是否已创建程序名是否匹配外部启动无响应模式是否AUTO、急停/门联锁是否复位、$PNS_SELECT是否使能偶发跑错程序PNS权重是否映射错位、稳定延时是否足够、PLC是否意外改写输出程序跑完后无法再次启动程序末尾是否缺少CLR_PNS指令PNSTROBE给了机器人不锁存PNSREQ是否同时有效、UI映射是否冲突、通信字节序是否正确这些报警有一个共性根因——信号时序不满足。所以我在现场调试时习惯把PLC侧和机器人侧的信号状态通过HMI做一个“PNS调试页面”把8位PNS信号的实时状态、选通脉冲状态、当前锁存程序号全部显示出来。出了毛病一眼就能定位。5. 进阶KAREL与后台任务读取PNS状态5.1 什么时候需要上KAREL用“程序名编号”的方式虽然简单但有些场景玩不转。比如程序号不是一个简单的编号而是一个编码规则复杂的产品代码或者PNS程序号需要与MES系统里的配方号联动。这时需要在后台做一层逻辑转换把PNS程序号翻译成实际要执行的工艺程序。FANUC系统支持KAREL语言编写后台任务在后台任务里可以读取PNS相关的系统状态变量做判断和转换再通过寄存器或标志位告诉TP程序该执行哪套工艺。5.2 $SBR[n].$PARAM[47]的用途FANUC系统里$SBR[n]代表后台任务Background Routine相关系统变量$PARAM[i]则表示该任务的参数寄存器。热词里提到的$SBR[n].$PARAM[47]在PNS相关的KAREL应用中通常用于后台任务之间或后台任务与主任务之间传递控制参数。实际项目中我见过有人用这个变量在后台任务里记录“上一次PNS选择的历史程序号”配合报警日志做追溯也有人用它作为PLC与KAREL后台任务之间的临时数据交换区。不过一个现实情况是$SBR[n].$PARAM[47]的含义在不同软件版本、不同选项配置下可能有差异。用之前一定要在Roboguide的KAREL调试窗口里监视这个变量确认它的实际取值和变化规律再把它写进正式逻辑里。盲抄网上的代码很容易踩版本差异的坑。5.3 KAREL和PLC的分工我的建议是KAREL只做一件事把PNS程序号转换成工艺程序名或者做PNS状态的复杂判断。所有的信号收发、时序控制、联锁互锁都留在PLC里做。不要试图用KAREL去替代PLC的时序逻辑KAREL的一个优势是灵活一个劣势也是灵活——写得随意了排查起来非常痛苦。举个例子我在一个多车型项目中PLC通过PNS发的是车型代码1~12但每个车型对应的工艺程序在机器人侧是“MODEL_01_WELD”、“MODEL_02_WELD”这种命名。如果用“程序名编号”的方式就得在PLC侧维护一张车型到程序号的映射表。后来改成KAREL后台任务后车型代码直接进KAREL程序内部做字符串拼接和校验再通过寄存器告诉TP程序要调用哪个程序。这样PLC侧只关心信号时序程序选择的业务逻辑全部收拢在KAREL里两边各管一头逻辑清晰了很多。最后再说一个容易被忽略的细节PNS程序启动后如果中途PLC切了新的程序号过来机器人不会立刻响应。当前程序会继续执行完直到收到新的选通脉冲并且旧程序已经完成复位才会执行下一次切换。这是FANUC的安全机制不是故障。现场调试时很多人以为“切换程序号就能中断当前程序”发现不行就以为是坏了其实是机制设计如此。理解了这一点你再去设计PLC端切换时序就不会卡在这种“伪故障”上了。本文还有配套的精品资源点击获取
