企业官网建设流程全解析

简介：这份PDF文档是发那科数控系统PMC功能的系统化技术说明，面向数控机床调试工程师、电气设计人员及PMC程序开发者，重点讲解PMC的梯形图三级程序结构、系统信号、数据形式与功能指令体系。内容基于0i-D与0i Mate-D系列机型，详细说明了执行周期、I/O Link信号点数、T/C/K/D/A地址范围等硬件规格，并逐一分析了定时器、计数器、数据传送、数值比较、算术逻辑运算、代码变换、CNC关联以及程序控制等指令的用途与编程要点。同时，文档对带符号二进制、BCD码、位型和格雷码的特点与转换方法做了专门讲解，并结合诊断画面说明数据长度、初始地址及高低字节排布规则，便于实际排错。整份资料为单个PDF文件，容量约831KB，目前已有637人学习下载。通读后能够帮助读者建立清晰的PMC编程思路，快速掌握信号分配、数据格式处理与常用功能指令的组合应用，为现场调试和故障诊断提供实用参考。 在FANUC数控系统和机器人的调试现场，PMC大概是出现频率最高的三个字母之一。无论是机床的换刀、冷却、润滑，还是机器人外部轴的互锁、夹具动作，几乎所有开关量控制都活在PMC梯形图里。但很多人第一次打开梯形图时，会下意识把它当成一台“焊在机床里的PLC”来理解，结果连X、Y、G、F这些地址的方向都搞反，更不用说后面那堆SUB指令了。这几年我调试过不少FANUC 0i系列和R-30iB控制装置，也带过几个刚入门的电气工程师，发现真正能把PMC地址体系、功能指令和调试工具串起来的人并不多。这篇文章就从PMC的角色定位、地址地图、功能指令、仿真调试，一路讲到与KAREL机器人程序的数据交互，争取让大家看完就能上手。

1. PMC不是“外挂PLC”：它在FANUC系统里的真实位置

1.1 硬件上共用大脑，职责上各管一摊

PMC全称Programmable Machine Controller，翻译过来是“可编程机床控制器”。它在硬件上并不是一块独立的PLC，而是直接坐在CNC单元内部，与CNC共用CPU、电源和总线。这意味着梯形图程序扫描到的信号并不需要经过外部接线，而是在内存里直接交换。你看到的X、Y、G、F地址，本质上是CNC与PMC之间约定好的一块共享内存区域，不是物理端子上的继电器触点。

它的职责可以这样理解：CNC负责轨迹计算和伺服控制，比如插补、位置环、速度环；PMC负责“机床侧的逻辑”，比如按一下循环启动按钮、主轴正转、冷却打开、换刀到位、门锁互锁。两者之间通过G地址（PMC给CNC的请求）和F地址（CNC给PMC的状态）来配合。打个比方，CNC像一个专注赶路的司机，PMC是副驾驶，负责看路牌、打转向灯、开关车门，但方向盘始终在司机手里。

机器人控制装置也一样。R-30iB、R-30iB Mate这类控制柜内部同样运行着PMC程序，外部IO、夹具、气动元件、输送线信号，都是PMC在管。维修手册里关于PMC的那一章，和数控车床铣床的处理思路是相通的。所以别把PMC理解成某个机床品牌独有的东西，它是FANUC控制系统的通用底层逻辑。

1.2 一级程序、二级程序与扫描周期

PMC梯形图不是像普通PLC那样从头到尾循环扫描一遍就完事，它把程序分成一级程序和二级程序。一级程序固定在每个插补周期都会执行，专门放急停、超程、回零减速这类必须在毫秒级响应的信号；二级程序则处理其余所有逻辑，按照系统设定的周期调度执行。

这个分层非常关键。我见过有人把所有逻辑都堆在一级程序里，结果扫描时间暴涨，反而把安全信号拖慢了。正确做法是：一级程序只保留最短、最必要的安全链，比如急停、超程、回零开关；其余像换刀、冷却、润滑、信号灯，统统放进二级程序。判断程序是否过长，可以在PMC的SETTING画面里看当前扫描时间，正常在几毫秒到十几毫秒之间，如果明显偏大，就要检查是不是有太多逻辑挤在了一级程序里。

另外，机器人控制装置的PMC扫描和CNC是同一个套路，只是硬件平台不同。搞机器人调试的朋友不要觉得“PMC是机床的东西”，实际上你示教器里看到的I/O互锁逻辑，底层就是PMC梯形图。

2. 先背地址地图：X/Y/G/F/R/K/A/T/C/D各管什么事

2.1 从一张表看懂地址区

PMC程序的阅读难度，很大一部分来自地址类型太多。普通PLC一般就是I/Q/M/D，PMC则分了X、Y、G、F、R、K、A、T、C、D一大串。第一次看确实头大，但它们各管一摊，搞清楚之后逻辑就顺了。

2.2 地址方向最容易搞反

X和Y一眼能分清方向，问题就出在G和F上。很多新人理解成“G是CNC给过来的信号”，实际上反了。G是PMC送给CNC的请求信号，例如循环启动、轴互锁解除；F是CNC反馈给PMC的状态信号，例如“当前在自动模式”“主轴速度到达”。判断方法很简单：G开头的是你要求CNC去做的事，F开头的是CNC告诉你它现在的状态。

地址本身按字节编址，每个字节又有0~7共8位。比如X8.2就表示X8这个字节的第2位。R100、R101两个字节组合起来可以做16位字操作，D类型还能做32位双字操作，这在比较刀号和传递数据时会用到。梯形图里的位、字节、字操作，对应的就是你在PMC参数里用16位还是32位来处理同一块数据。

2.3 动手前先花半小时做信号分配

我自己的习惯是，接触一台新设备先不看梯形图，而是把IO清单打开，用表格列出每个X、Y分别接了什么，每个G/F在程序里控制什么。很多“奇怪故障”最后都能追溯到信号规划混乱，比如同一个X点被两个传感器并联，或者某个Y口接了不同电压等级的负载。

这一步没有技术难度，但极其养人。磨刀不误砍柴工，信号规划清楚了，后面写梯形图和排故障都能省一半时间。反过来，如果信号分配本身是乱的，梯形图写得再漂亮也救不回来。

3. 功能指令拆解：从定时器到数据表的常用素材

3.1 常用指令一览

PMC的指令集和三菱、西门子的PLC不完全一样。FANUC自己的指令都带SUB编号，写梯形图和看图纸时经常直接说“这个SUB几”。常用的我列一个表，供查：

3.2 定时器、译码和查表的高频用法

定时器最典型的场景是“按钮按下后延时启动”“到位后延时2秒再夹紧”。可变定时器TMR的时间放PMC参数里，调试时可以随时改，不用重新下载梯形图；固定定时器TMRB则适合那些“永远不应该改”的安全类延时，比如阀动作后的确认时间。两者区别很实用：TMR适合现场调，TMRB适合定型后锁死不让人乱动。

DECB译码指令是M功能处理的主力。比如系统执行M03主轴正转，会在相应F地址送出M代码，DECB把当前M代码和设定值比较，相等就把后面指定的结果位置1，之后再由这个结果位去驱动Y输出或置位R标志。这样做的好处是，M代码和实际输出的对应关系全集中在译码指令里，排查问题一目了然。换刀时的T代码、主轴定向、冷却开合，都可以用同一套路处理。

CODB查表转换也很有用，尤其是刀库。T指令给出的是目标刀号，但物理刀套号和刀号不一定对应，CODB就是拿目标刀号去查一张表，表里存着对应的刀套号，查出来的值再去驱动刀库动作。D区数据表在这里充当了“查表”的主角，中央刀库、圆盘刀库都靠这个逻辑实现。

3.3 计数器为什么总是乱跳

计数器CTR本身并不复杂，但现场“计数不准”的故障十有八九出在计数脉冲没有处理上升沿。比如用一个接近开关的X信号直接去驱动计数器，开关抖动一次，扫描周期里看见了两次上升沿，计数器就计了两次。

解决办法是给计数信号加上升沿微分，FANUC的梯形图里有专门的上升沿检测指令，也可以用“当前状态 AND 前一次状态的非”来写一个等效的脉冲输出。一般我写计数逻辑时，先做一个“上一次状态”的中间变量，每次扫描更新一次，只有从0变1才算一个脉冲。这一步加不加，直接决定计数器在现场能不能用。

4. 从Ladder-III到NCGuide：离线仿真与下载

4.1 梯形图编辑器选哪个

FANUC系统自带的编辑器只能在机床上看梯形图，真正用来写程序、改程序、做离线仿真的是PC端的FANUC Ladder-III。它可以直接新建梯形图项目，也可以从CF卡或存储卡里把机床上的.000文件读出来编辑，修改完再编译生成新的PMC程序文件。

Ladder-III的安装包一般随FANUC系统资料一起，向代理商申请即可。版本要和系统匹配，下载时如果提示程序版本过高，多半就是Ladder-III版本选新了。另外，无论从哪里拿到安装包，我建议装在一个干净的Windows环境里，虚拟机里也能跑，但早期版本对USB授权狗不太友好，VMware里容易识别不到。

4.2 用NCGuide把整机逻辑跑起来

没有实物机床又想练PMC，最方便的办法是NCGuide。它相当于一个运行在PC上的虚拟CNC，可以加载PMC梯形图、设置参数、模拟运行。网上经常能看到类似“vmware fanuc ncguide.part04”这种分卷压缩包，说明下载资料是以多个分卷发布的，解压时所有part必须放在同一目录，缺一个卷或者解压路径不对都会失败。

在NCGuide里跑PMC，流程大致是：先把梯形图编译生成PMC文件，放到NCGuide项目指定目录，然后在参数里把PMC加载方式设好，启动后就能在虚拟系统里看梯形图运行、置位输入、观察输出。调试机器人的朋友可以类比Roboguide，它同样能把机器人控制装置的PMC程序加载到虚拟控制柜里跑，配合KAREL后台程序做整线仿真。这套组合对于没有设备、又想提前验证逻辑的人来说，价值非常高。

4.3 下载到实机前的最后检查

真实机床下载PMC程序的路径有两种：插CF卡导入，或者用网络FTP传到系统BOOT画面。无论哪种，下载前一定要做两件事：一是把原梯形图完整备份成.000文件，二是把当前PMC参数区里的K参数、定时器、计数器、数据表全部导出。见过太多人只备份梯形图，恢复的时候发现K参数全丢了，刀库数据全乱。

下载完成后要断电重启，注意重启后先在PMC画面确认程序版本和编译时间，再逐个验证关键信号。如果下载后系统直接报警，优先检查是不是程序文件名称不对、写保护没解除、或者系统版本不支持当前PMC功能指令。这些问题十有八九是版本或文件格式问题，不是逻辑本身写错了。

5. PMC与KAREL/机器人程序的数据交互

5.1 让机器人程序知道PMC在想什么

很多自动化项目里，机器人不是孤立运动的，它需要知道“夹具夹紧没有”“安全门关没关”“顶升机构退没退”，这些信号都在PMC里。传统做法是把关键信号映射到机器人数字IO，然后在TP程序里判断某个DI；但信号一多、逻辑一变，IO映射表就变得难维护。KAREL程序更灵活，可以在代码里直接读取或写入与PMC共享的数据区。

这也是为什么很多进口产线程序里会出现$SBR[n].$PARAM[m]这种写法。它读的不是PMC内存的原始地址，而是经过控制柜I/O分配映射后的一个系统存储区。n代表第几个SBR块，m代表块内的第几个参数槽。具体编号不能拍脑袋定，必须对着示教器上的I/O分配表确认，不同版本的控制柜映射规则会有差异。

5.2 KAREL示例：读取和写入

读取PMC数据，KAREL里用GET_VAR，格式大致是这样：

PROGRAM READ_PMC_PARAM VAR status : INTEGER value : INTEGER BEGIN GET_VAR(MPNUM[1], 0, "$SBR[1].$PARAM[47]", status, value) IF status = 0 THEN WRITE('PMC PARAM value = ', value, CR) ELSE WRITE('Read failed, status = ', status, CR) ENDIF END READ_PMC_PARAM

status返回0代表读取成功。如果想写入，用SET_VAR，把最后一个参数改成要写入的值即可。还有更通用的方式，直接读数字IO系统变量，比如$DIN[17]、$DOUT[9]，这类变量在绝大多数机器人控制柜上都稳定可用，适合不需要访问PMC内部R地址、只要看外部IO状态的场景。

5.3 实测中要留意的细节

第一，读写权限不同。很多PMC数据区对机器人程序是只读的，你用SET_VAR去写，状态码会直接返回错误，不要硬写。第二，写入PMC数据可能影响设备动作，写之前一定要确认当前状态安全，最好加一个“手动/自动”或“调试模式”的判断。第三，有的控制柜要启用“PMC访问”相关选项，不是所有版本都开放。碰到读不出来，先查选项和I/O映射，再查权限，最后才是查程序语法。

6. 现场调试常踩的坑

6.1 偶发超程报警：一次完整的排查链路

有台设备自动运行时，X轴偶尔报超程，机械限位开关换了两次，问题照旧。梯形图里看，超程信号直接映射到轴互锁G地址，逻辑很简单，就是机械震动导致限位开关瞬时抖动，PMC正好扫到这个抖动，轴就停了。

排查链路供参考：

1. 在Ladder-III里在线监视超程输入X点，盯一会儿能看到它偶尔闪一下；
2. 到信号状态画面看该输入对应地址是否跟着抖，确认不是地址映射错误；
3. 用示波器或万用表监测开关触点电压，确认是机械抖动而不是接线虚接；
4. 修改PMC参数里该输入点的滤波时间，或者在梯形图里加一个“确认延时”，让信号稳定10~20ms后再参与互锁；
5. 恢复自动运行，连续空跑验证。

这类故障最怕上来就怀疑PMC程序，其实很多时候是输入信号的物理质量不过关。先看信号状态，再动程序，顺序不能反。

6.2 计数器规律性多计、漏计

计数不准先检查是不是没有上升沿微分；再检查计数器类型和预置值设置；最后用强制信号的方式在梯形图里手动给一个脉冲，看计数器动不动。如果手动给脉冲正常、现场乱跳，那基本就是现场信号抖动或干扰，加滤波比改程序更有效。

6.3 R地址被多段程序同时写

R地址作为中间变量非常好用，但写着写着就会出现“明明没有动A段逻辑，结果R100的值被改了”。原因通常是另一段程序也在写同一个R地址。Ladder-III里可以直接搜索某个R地址被哪些触点引用，把所有写它的地方全部找出来，再决定是换地址还是统一逻辑。程序结构上，建议每个功能块使用独立的一段R地址区间，不要东写一个西写一个。

6.4 PMC版本与系统版本不匹配

新写好的PMC程序在旧系统上下载后，系统状态画面直接红屏报警，查看内容全是“PMC function illegal”这类信息。原因是PMC功能指令版本比系统版本高。遇到这种情况没有捷径，要么把系统升级，要么把PMC程序里用到的指令降级。下载前在Ladder-III编译信息里仔细看指令版本要求，能少走很多弯路。

6.5 备份永远不嫌多

每次修改PMC前，把旧版本的.000和参数表导出并写上日期。产线设备不比实验室，改挂了是要停线的。我自己的习惯是，同一个程序改三版，文件名后面带_v1_20250115这种格式，旧文件不删。三个月后你回头看，会感谢当时的自己。

最后再说一点个人体会。调试PMC这么多年，最大的感受是：PMC程序写得再花哨，不如信号规划清晰；排查故障时，先看信号状态、再看梯形图、最后动程序，顺序别搞反。遇到看似诡异的故障，九成都是输入信号抖动、地址映射错、版本不匹配这三类问题。你如果有空，可以把自己设备上的PMC程序从头到尾通读一遍，把每个G/F地址的含义标出来，这个过程比看十篇文档都管用。

本文还有配套的精品资源，点击获取