FOCAS2开发实战：FANUC数据采集

FANUC机床数据采集：深入掌握FOCAS2开发实践（含C语言源码）

在现代智能工厂中，数控机床不再是孤立的加工单元，而是生产数据流的关键节点。尤其是在汽车零部件、航空航天精密制造等高要求领域，对设备运行状态的实时感知能力，直接决定了产线的响应速度与管理精度。FANUC作为全球装机量最大的CNC系统供应商，其设备遍布各类高端制造场景。如何高效、稳定地从这些设备中提取关键数据？答案正是—— FOCAS2 。

这不仅是连接上位系统与底层控制器的技术桥梁，更是一套被工业界验证过的原生数据接入方案。不同于Modbus这类通用协议的“黑盒式”读取，FOCAS2提供了直达CNC内核的数据访问能力，允许开发者读取主轴负载、当前程序段、坐标位置、报警代码等数十类核心信息。然而，由于官方文档全英文且缺乏完整示例，许多国内工程师在初次接触时往往卡在环境配置或函数调用细节上。

本文将带你绕过这些“坑”，以实战视角解析FOCAS2的核心机制，并结合可运行的C语言代码片段，还原一个真实的数据采集服务构建过程。

---

我们先来看一个典型的使用场景：某自动化车间部署了8台FANUC 0i-MF系统的立式加工中心，现在需要为MES系统提供每台机床的实时状态监控功能，包括是否正在运行、当前执行的是哪个程序、XYZ三轴的实际坐标以及是否有报警发生。传统的做法是人工巡检或依赖操作员上报，效率低且容易遗漏。而通过FOCAS2接口，这一切都可以实现秒级自动采集。

要实现这个目标，第一步就是建立通信链路。FOCAS2本质上是一个基于TCP/IP的客户端-服务器架构，其中CNC控制器充当服务器端，默认监听 端口8193 。你的PC应用程序作为客户端，加载FANUC提供的动态库（ fwlib32.dll 或 fwlib64.dll ），并通过标准Socket完成握手和数据交换。整个过程无需中间件，也不依赖OPC UA服务器或其他代理软件，结构简洁、延迟极低。

那么具体怎么写代码呢？

首先确保你已经从FANUC官网申请并获得了FOCAS开发包，里面包含头文件 fwlib.h 、静态库 fwlib32.lib 以及最重要的DLL文件。将 fwlib32.dll 放在你的可执行程序同目录下，然后开始编码：

#include "fwlib.h"

short handle;
char ip[] = "192.168.1.100";
unsigned short port = 8193;
long timeout = 5000;

// 尝试连接
short ret = cnc_allopen(ip, port, timeout, &handle);
if (ret != EW_OK) {
    printf("连接失败，错误码: %d\n", ret);
    return -1;
}
printf("连接成功，句柄: %d\n", handle);

这段代码看似简单，但背后涉及多个关键点。比如 cnc_allopen() 不仅负责建立TCP连接，还会进行版本协商和初始化握手。如果返回 EW_SOCKET ，说明网络不通；如果是 EW_VERSION ，则可能是DLL版本与CNC固件不兼容。常见问题还包括CNC侧未开启远程诊断模式，或者I/O通道未设置为以太网（通常需设为4）。建议在调试阶段配合ping和telnet命令验证连通性。

一旦连接成功，接下来就可以按需读取各类数据。例如获取机床当前运行状态：

ODBST odbs;
short result = cnc_rdstat(handle, &odbs);
if (result == EW_OK) {
    const char* state_str[] = {"停机", "运行", "暂停"};
    printf("当前状态: %s\n", state_str[odbs.run_state]);
    printf("主轴转速: %d rpm\n", odbs.s_spdl);
    printf("进给速度: %d mm/min\n", odbs.f_feed);
}

这里使用的 ODBST 结构体封装了丰富的状态字段。值得注意的是， run_state 值为1表示“自动运行”，2为“暂停”（M00或单步），而急停状态则由另一个字段 emergency 反映。很多初学者误以为运行状态只有开/关两种，实际上FANUC的状态机更为精细，这对准确判断OEE中的“可用时间”至关重要。

如果你关心的是空间位置信息，可以使用 cnc_rddynamic2() 函数批量读取多维数据：

ODBAXIS axis_data;
short axes = 3; // X/Y/Z
result = cnc_rddynamic2(handle, ALL_AXS, DYNAMIC_POS, sizeof(ODBAXIS), &axis_data);
if (result == EW_OK) {
    for (int i = 0; i < axes; i++) {
        printf("轴%c: %.3f mm\n", 'X'+i, axis_data.data[i].prg);
    }
}

相比老式的 cnc_rdpos() ， cnc_rddynamic2() 支持一次调用获取位置、速度、负载等多种动态参数，显著减少通信次数，提升采集效率。这对于高频采样场景尤为重要——想象一下每秒采集一次坐标用于轨迹分析，若每次都要单独发起请求，网络负担会急剧上升。

再来看一个实用功能：读取当前正在运行的NC程序名。这对生产追溯非常有价值，尤其在多批次混线生产时：

IODBPRMOD prg_info;
result = cnc_rdprgname2(handle, &prg_info);
if (result == EW_OK) {
    printf("当前程序: %s, 段号: N%d\n", prg_info.name, prg_info.block);
}

该函数能精确返回带路径的程序名称（如 O1234.MPF ）和当前执行到的行号，结合外部数据库即可实现加工进度跟踪。类似的，还可以通过 cnc_rdalarm() 读取当前激活的报警列表，提前发现潜在故障。

当然，实际项目中不可能只采集一台设备。面对多台机床，必须设计合理的资源管理策略。常见的做法是采用 线程池 + 句柄池 模型：

• 每个CNC连接分配独立的工作线程；
• 线程内部定时轮询不同数据项（如状态每1秒一次，报警每10秒一次）；
• 使用全局队列汇总数据，统一推送至MQTT Broker或本地数据库；
• 添加心跳检测和断线重连逻辑，保障长期运行稳定性。

下面是一个简化的多机连接管理思路：

typedef struct {
    char ip[16];
    short handle;
    int connected;
} Machine;

Machine machines[10] = {{"192.168.1.100"}, {"192.168.1.101"}};

void* collect_thread(void* arg) {
    Machine* m = (Machine*)arg;
    while (1) {
        if (!m->connected) {
            if (cnc_allopen(m->ip, 8193, 5000, &m->handle) == EW_OK) {
                m->connected = 1;
                log_event(m->ip, "connected");
            } else {
                sleep(5); continue;
            }
        }

        ODBST st;
        if (cnc_rdstat(m->handle, &st) == EW_OK) {
            publish_json(m->ip, "status", st.run_state);
        } else {
            cnc_freelibhndl(m->handle);
            m->connected = 0;
            log_event(m->ip, "disconnected");
        }

        sleep(1);
    }
}

这种设计既保证了各设备之间的隔离性，又便于集中管理和日志追踪。同时建议设置统一的错误码翻译函数，把 EW_BUFFER 、 EW_BUSY 等数值转换成可读提示，大幅降低运维难度。

说到性能优化，有几个经验值得分享：

• 避免高频小请求 ：尽量合并读取，优先使用 cnc_rddynamic2 而非多次调用单一读取函数；
• 控制采集频率 ：对于非关键变量（如刀具寿命、参数表），可降低至分钟级；
• 启用连接复用 ：不要每次读取都重新连接，保持长连接状态；
• 谨慎使用写入操作 ：除非明确需求，否则禁用 cnc_wrparam 等写函数，防止误操作导致停机。

安全性方面也要特别注意。虽然FOCAS2本身没有内置认证机制（仅靠IP白名单和端口开放控制），但在生产环境中仍应采取以下措施：

• 将采集PC置于独立VLAN，限制外部访问；
• 关闭不必要的共享和服务；
• 记录所有异常事件（如频繁断连、非法指令）；
• 定期备份关键参数，防止配置丢失。

最终的数据流向通常是这样的：采集服务将原始结构体序列化为JSON格式，通过MQTT发布到本地边缘网关，再由后端服务存入InfluxDB或MySQL，供Web前端展示或供AI算法分析。整个链条中，FOCAS2扮演着最前端也是最关键的一环——它决定了你能拿到什么级别的数据粒度。

值得一提的是，尽管FOCAS2功能强大，但它并非万能。例如它无法直接获取PLC梯形图运行状态，也不能替代伺服调试工具。它的定位很清晰： 为上层应用提供可靠、低延迟的CNC运行数据支撑 。正因如此，Predator、Scytec等主流DNC/MDC软件均基于此构建，形成了成熟的生态体系。

展望未来，随着边缘计算的普及，我们可以预见更多轻量化、容器化的FOCAS采集代理出现在现场。比如用Go语言编写的小型Daemon，打包成Docker镜像运行在ARM架构的工控盒上，配合Kubernetes实现集群调度。这种架构不仅能降低对Windows系统的依赖，还能更好地融入云原生智能制造平台。

回到最初的问题：为什么选择FOCAS2？因为它是由FANUC官方维护的唯一深度接口，具备最高的数据完整性与稳定性。相比之下，Modbus TCP只能映射有限寄存器，而OPC UA虽标准化程度高，但在部分旧机型上支持有限且需额外授权。FOCAS2则完全免费（只要CNC允许网络访问），并且持续更新，至今已支持30i等最新控制系统。

当你真正跑通第一个 cnc_allopen() 调用，看到屏幕上打印出“连接成功”的那一刻，你就已经迈出了构建自主数据采集平台的第一步。后续无论是做OEE看板、预测性维护，还是数字孪生建模，都有了坚实的数据基础。

技术的价值不在炫酷，而在落地。FOCAS2或许不够时髦，但它足够扎实，足够可靠——而这，正是工业级应用最需要的品质。