简介：面向法兰克数控系统二次开发的Focas2开发包，专注解决机床数据交互与功能扩展问题，适合设备集成工程师、工业软件开发者及智能制造团队。压缩包共6797个文件，整体约25.68MB，以xml配置和htm说明文档为主体，另含doc手册、dll链接库、h头文件、exe工具、vb/cs示例工程与xsl样式表，覆盖接口定义、开发环境配置、测试用例及操作界面示例。包内同时保留Focas1与Focas2两代资料，便于对照版本差异或兼容旧设备。借助Fwlib32库，开发者能编写程序自动发送G代码、读取机床坐标与刀具信息、采集加工过程数据，并扩展报警监控、自动换刀或报告生成等能力。已有2726人浏览学习，适合需要深入研究法兰克数控通信协议、构建设备互联方案的技术人员。 车间设备联网做了这么多年，我越来越觉得 FOCAS2 开发包是一道绕不开的门槛。不管你是做 MES 设备数据采集，还是搞自动化上下料，只要现场躺着几台发那科系统，就迟早得跟这个接口打交道。FOCAS2 是发那科官方提供的以太网通信开发包，专门用来从 CNC 系统里往外取数据，也能做有限度的远程控制。它的价值在于：不碰机床电气线路，不需要额外加传感器，一根网线就能把设备的实时状态、坐标、程序号、报警这些信息一两秒刷新一次地抓到上位机。
这篇文章我想把 FOCAS2 开发包从原理到落地串一遍，包括机床侧怎么配置、上位机代码怎么写、现场会踩哪些坑，以及它和机器人 SDK（比如现在常说的 UR 系列配套 SDK 开发包）在自动化项目里怎么分工配合。适合正在做设备联网的工程师、搞机器人集成的朋友，还有准备上 MES 又不知道数据从哪来的生产管理人员参考。
1. FOCAS2 开发包到底解决了什么问题
1.1 发那科数控系统的“对外接口”是怎么工作的
发那科系统本身就是一个封闭的嵌入式系统，屏幕上的坐标、负载、报警都只在系统内部流转。想把这些数据拿出来，传统做法是走 IO 点硬接线，或者让操作工天天手抄报表。FOCAS2 的出现改变了这个局面，它的全称是 FANUC Open CNC API Specification，本质上是发那科在系统里常驻了一个以太网服务端，对外提供一组基于 TCP 的私有协议接口，上位机通过官方动态库调用这些接口，就能以结构体的形式拿回机床状态。
这个设计思路很像路由器后台的网管接口：设备本身就带着对外通信能力，你只要知道地址、端口和协议格式，就能请求数据。FOCAS2 开发包就是发那科提供给开发者的“协议说明书 + 现成库文件”。官方包里包含动态库 Fwlib32.dll 和 Fwlib64.dll、头文件、PDF 文档和大量示例程序。实际开发中，你不需要自己解析二进制报文，所有数据都封装成了 C 函数调用，返回值就是机床数据。
1.2 能取到哪些数据、能做什么控制
FOCAS2 的能力范围很广，基本上机床屏幕上能看到的数值，大部分都能读出来。我用过比较频繁的功能有这几个：系统运行状态和当前模式（自动、手动、MDI）、各轴绝对坐标和机械坐标、主轴转速和负载、当前程序名和执行行号、宏变量、报警信息、刀具号、加工计数、运行时间等。部分系统还支持读写 PMC 信号和部分系统参数。
| 功能分类 | 典型接口 | 典型用途 |
|---|---|---|
| 连接管理 | cnc_allclibhndl3 / cnc_freelibhndl | 建立和断开通信 |
| 状态读取 | cnc_rdstat / cnc_rdmode | 设备开机状态、运行模式 |
| 坐标读取 | cnc_rdaxisdata / cnc_rdposition | 各轴位置监测、加工路径记录 |
| 主轴数据 | cnc_rdspindle | 主轴转速、负载、倍率 |
| 程序数据 | cnc_rdprogram / cnc_rdexecprog | 程序名、当前行号 |
| 宏变量 | cnc_rdmacro / cnc_wrmacro | 读取工艺参数、写入用户宏 |
| 报警读取 | cnc_rdalarminfo | 故障报警采集推送 |
| PMC 访问 | pmc_rdpmcrng / pmc_wrpmcrng | 读写 PMC 地址信号 |
需要注意的是，FOCAS2 虽然支持写入，比如写宏变量、写 PMC，但实际项目里我只建议在设备离线或者工艺明确允许的情况下做写操作，否则很容易干扰机床正常运行。
1.3 什么时候你会需要它
判断项目是否要上 FOCAS2，主要看两个问题：设备是不是发那科系统，数据要不要自动进系统。早期很多工厂用串口输出到打印机，或者靠按钮盒指示灯做联机信号，都已经过时了。现在做 MES、做精益生产看板、做刀具寿命预警、做自动上下料，都需要稳定的实时数据源。只要机床上没有其他工业网关在转发数据，FOCAS2 就是最直接、最低成本的接口方案。尤其是那些 OTC 老设备没有数据输出能力的场景，FOCAS2 几乎是唯一可行的软采集路径。
2. 开发前必须知道的软硬件要求
2.1 机床侧设置：以太网功能和端口是前提
很多工程师拿到开发包就写代码，结果连接永远失败。原因十有八九是机床侧没打开通信开关。发那科系统默认是不对外提供 FOCAS2 服务的，需要从系统画面里手动开启。进入系统设置界面，把以太网功能设为有效，给控制单元分配一个固定 IP，和上位机保持在同一网段，端口要保持默认的 8193。另外还有个后台通信开关，位置在系统参数或者 PMC 里，具体路径不同系列略有差异，但逻辑一样——不打开它，上位机发的 TCP 请求机床根本不会响应。
还有一点容易被忽略：不少系统对 FOCAS2 连接数有限制，一般是 1 到 4 个。调试时如果上位机开了多个测试程序，后连的会被拒绝。我习惯用一台专门的采集工控机作为网关，所有业务系统都从这台机器上拿数据，避免多客户端抢连接。
2.2 上位机侧：动态库选择和开发语言
FOCAS2 官方动态库分 32 位和 64 位，Windows 下是 Fwlib32.dll 和 Fwlib64.dll，Linux 下对应 libfwlib32.so 和 libfwlib64.so。选择 DLL 版本要跟你的编译目标一致，32 位进程只能加载 32 位库，64 位进程只能加载 64 位库，混用会直接加载失败。
开发语言方面，官方示例以 C/C++ 为主，但实际项目里 C#、VB.NET、Python 都很常见。C++ 适合做高性能采集服务，C# 写界面和中小型工具效率很高，Python 用 ctypes 调用也很灵活，适合快速验证。我个人常用的组合是 C++ 写采集服务，C# 写配置界面，两边通过共享内存或者数据库对接。不管什么语言，思路都一样：加载动态库，建立连接，调用接口，处理返回码。
2.3 和机器人 SDK 的配合：UR 系列只是另一种思路
做自动化集成项目时，FOCAS2 往往不是唯一的开发包。比如现在常被提到的 UR 系列协作机器人配套 SDK 开发包，就提供了机器人端的控制接口，用于控制机械臂动作、读取关节状态、接收视觉引导结果。UR 侧的 SDK 偏向“动作控制”，FOCAS2 偏向“设备数据采集”，两者各有各的边界。像一些带视觉引导的 r330 套装，其实就是把相机标定、手眼配合、路径规划打包成一个应用层 SDK，方便集成商直接在机器人侧做视觉逻辑。
在实际产线里，我的建议是不要把两个开发包的责任混在一起。机器人和 CNC 的联锁信号，优先走 PLC 或者中间状态服务器，不要在两边开发包里直接互相调用，否则排障起来非常痛苦，后面第 5 节我会细说。
3. 从零搭建第一个 FOCAS2 读取程序
3.1 建立连接的流程与参数选择
FOCAS2 的开发套路非常固定，第一步永远是连接，连接函数的签名各系列基本一致。以 C++ 为例，核心代码是这一段：
#include "fwlib32.h" #include <cstdio> int main() { unsigned short handle = 0; short ret = cnc_allclibhndl3("192.168.0.100", 8193, 3, &handle); if (ret != EW_OK) { printf("connect failed, ret=%d\n", ret); return -1; } ODBACT act; ret = cnc_rdact(handle, &act); if (ret == EW_OK) { printf("program name: %s\n", act.program); printf("sequence no: %d\n", act.sequence); } cnc_freelibhndl(handle); return 0; }连接函数里最重要的参数是超时时间，指的是 TCP 层握手等待。现场网络环境复杂，我一般设 3 秒，太短容易误判故障，太长会导致操作界面卡顿。建立连接后，后续所有读取函数都要传这个 handle，相当于一把钥匙。程序退出或者设备掉线时，记得调用 cnc_freelibhndl 释放连接，否则连接数被占满，机床侧拒接新请求。
3.2 读取坐标和主轴状态的实例代码
连接之后就可以按需调用各类读取接口。读坐标用的是 cnc_rdaxisdata，它返回的是结构体数组，每个轴一个元素。需要注意单位：系统参数决定了数据是公制还是英制，默认很多系统返回的是毫米，但某些老系统可能返回的是脉冲数，需要除以相应的计数倍率。
读主轴信息用 cnc_rdspindle，返回主轴转速、实际转速、负载、倍率等。这段代码我经常用在设备利用率计算项目里：
ODBSPINDLE spindle; short ret = cnc_rdspindle(handle, &spindle); if (ret == EW_OK) { printf("speed: %d rpm, load: %d%%\n", spindle.speed, spindle.load); }读主轴负载看起来简单，但有个细节：负载数据是模拟量经过系统换算后的百分比，并不是精确的电流值。做切削状态监测时要设定一个合理的阈值区间，不要期待它能替代电流传感器。另外，主轴启动瞬间负载会有一个尖峰，如果拿来做报警逻辑，最好加一个滤波窗口，比如连续 2 秒超过 110% 才判定为异常。
3.3 多台设备并发采集的线程模型建议
FOCAS2 的一个坑是，单个连接句柄同时只能执行一个调用，多个线程同时往同一个 handle 发请求，轻则超时，重则崩溃。要并发采集多台机床，我推荐的做法是：每台机床独立建立连接，每个连接用一个专用采集线程循环调度，线程内部加锁或者干脆不用锁，因为同一时刻只有一个请求在跑。
标准采集循环大概是这样的顺序：先读系统状态，再读当前程序名和行号，然后读坐标和主轴，最后读报警。把这些数据拼成一个结构体，按时间戳写入本地数据库或者 MQTT。采集周期一般设 500 毫秒到 1 秒，既能满足看板和 MES 需求，也不会给机床系统造成额外负担。有些工程师为了追求实时性把周期压到 100 毫秒，结果系统偶尔出现画面卡顿，得不偿失。
4. 现场常见问题与排查技巧
4.1 连接失败，先查这三样
连接失败是 FOCAS2 项目里出现频率最高的问题。我总结了一个排查顺序：第一步确认机床侧后台通信开关是否打开，这一步只能人去现场操作，代码层面无能为力；第二步确认 IP 和端口，用 ping 测试机床 IP，再用 telnet 测试 8193 端口通不通；第三步检查 Windows 防火墙，很多工控机默认拦截 8193 端口。
最常见的情况是前两步都没问题，但代码就是连接失败。这个时候用 Wireshark 在电脑上抓包，盯着 TCP 三次握手，一旦发现 SYN 发出去没有 SYN-ACK 返回，基本就是机床侧没开。如果能看到三次握手成功但马上收到 RST，那就是连接数满了或者后台通信参数不对。
4.2 读取超时和线程冲突
明明连接建立成功，但调用读取函数隔三差五返回超时，这种问题多半出在线程冲突上。FOCAS2 的接口不是线程安全的，全局句柄被多个线程并发调用就会出现随机超时。解决办法是每个连接对象内部做一个互斥锁，把所有读取函数包进锁里，或者用每线程独享连接的模型，彻底避开锁竞争。
超时还有一种原因是采集任务太多，机床侧处理不过来。发那科系统的 FOCAS2 服务优先级并不高，如果同时有好几个上位机在疯狂轮询，机床会主动丢弃部分请求。我做过一个极限测试，四个客户端同时每秒轮询坐标，一个小时后系统偶尔开始拒绝连接。所以生产环境一定要规范客户端数量和轮询频率，别让接口滥用拖垮机床。
4.3 乱码、字节序和数据类型
FOCAS2 返回的数据格式并不全是常规的整数和浮点数，很多字段是 BCD 码或者 ASCII 码。比如程序号、刀号这类字段，在结构体里是 char 数组，但装的是 BCD 编码，直接当字符串打印会得到一堆乱码。官方头文件里已经定义了对应的结构体类型，理论上只要按头文件定义取用就不会错，但现场经常有工程师过度解析，把一个 int 拆成两个 short，把 BCD 当十进制作运算。
最稳的做法是严格对照官方结构体定义写代码，不要自己推断字节顺序。比如读宏变量，cnc_rdmacro 返回的是一个 union，每个元素可能是数值型也可能是字符串型，需要根据宏变量的类型字段判断。这个判断逻辑宁可多写几个分支，也不要默认全是数值。
4.4 日志和抓包辅助定位
排查 FOCAS2 问题，我最依赖的就是日志。每个接口调用都记录返回码、调用时间、耗时，即使现场没有复现问题，也能事后从日志里看出端倪。FOCAS2 的返回码涵盖各种失败原因，有的是超时，有的是参数非法，有的是机床状态不满足，官方文档里都有解释，建议花一晚上把几个常见错误码背下来。
还有一个技巧是抓包。TCP 8193 端口的通信内容虽然是私有协议，但通信模式很清晰：请求包和响应包是成对出现的。如果看到请求包发出去后响应包间隔特别长，说明机床侧处理慢；如果压根没有响应，可能是连接被系统重置。抓包不需要看懂每个字节的含义，只需要看交互频率和响应延迟，就能快速定位瓶颈在哪一端。
5. 从单机采集到产线联动：一点扩展经验
5.1 把数据上抛到 MES 和看板
单机采集只是第一步，生产系统真正需要的是稳定的数据管道。我在项目里通常把采集服务做成独立进程，数据先写到本地时序数据库，再由另一个转发服务实时推送到 MES 或者看板。这样做的好处是解耦：MES 挂了不影响采集程序，网络波动也不会丢数据，本地缓冲可以事后补传。
数据字段设计上，每一条数据都要带机床唯一标识、采集时间戳、数据版本号，尽量用统一的订单号或者设备编号，方便下游系统做关联分析。如果数据直接进数据库，建议做分区表，按天分区，查询性能会好很多。要是走 MQTT，主题命名用“设备类型/设备编号/数据类型”的格式，订阅端处理起来会很顺手。
5.2 和机器人 SDK 的联动：一个典型上下料场景
拿 CNC 上下料项目举例。一台发那科加工中心旁边配一台 UR 协作机器人，FOCAS2 负责从机床读取“程序是否结束、门是否打开、夹具是否松开”这些状态信号，UR 机器人通过自己的 SDK 接到指令去取放工件。最关键的是时序配合：FOCAS2 读到加工完成信号后，通过中间层把状态置位，机器人侧的 SDK 程序轮询到这个状态，才执行取料动作；取料完毕，机器人反馈完成信号，FOCAS2 再通过写 PMC 或者宏变量通知机床程序继续下一步。
这里最容易出问题的就是两边时序不同步。如果机器人还没取完料，机床的程序已经开始装夹下一步，就会撞机或者夹坏工件。所以我强烈建议在中间加一个状态机，所有信号都放到这个状态机里流转，而不是让 FOCAS2 直接调用机器人 SDK，或者反过来。状态机负责做超时判断、异常复位、手动干预，两边开发包只做自己最擅长的事。
像 UR 系列那种带视觉引导的 SDK 套装，也是同样的逻辑。视觉识别结果先落到中间状态，再决定机器人的运动路径。搞清楚了边界，多套 SDK 配合其实没那么混乱。
5.3 权限、安全和可用性设计
FOCAS2 默认没有加密，数据是明文传输，而且它具备写操作能力，这就有潜在风险。我的做法是：采集网络用独立 VLAN，上位机固定 IP，只开放 8193 端口；写操作的接口单独封装，平时关闭，需要时由现场工程师手动开启；对外部系统只提供只读的 HTTP 或者 MQTT 接口，不给它直接面对 FOCAS2 的机会。
可用性方面，采集服务要加看门狗和自动重连。机床断电重启之后，FOCAS2 服务会自动起来，但上位机的连接已经断了，如果不重连，数据就会一直空缺。重连逻辑一般做成指数退避，首次 1 秒，之后 2 秒、4 秒、8 秒，最大不超过 30 秒，避免机床刚开机时反复尝试连接加重负荷。
做了这么多年设备联网，我越来越觉得 FOCAS2 开发包本身并不难，难的是对现场环境的敬畏。每一台机床的网络配置、系统版本、后台参数都不完全一样，你以为写好了通用代码，到现场大概率还要逐个适配。我现在的习惯是接到新项目，第一天先拿一台设备做最小验证，把连接、读坐标、读状态跑通，再复制到整个产线。如果你正准备上手 FOCAS2，不妨也用这个节奏，先小步走通，再铺开做，省下的全是返工的工时。
本文还有配套的精品资源，点击获取
