4、FOCAS协议体系结构：FOCAS库分层结构、核心组件（FWLIB、FOCAS1/2）、通信模型与数据流
FOCAS（FANUC Open CNC API Specifications）是发那科公司为其数控系统提供的开放式数据采集与通信接口规范。理解FOCAS的体系结构，是开发稳定、高效的数据采集监控系统的前提。本章将深入剖析FOCAS库的分层结构、核心组件（FWLIB与FOCAS1/2）以及通信模型与数据流，帮助学习者建立从硬件连接到上层应用的完整认知框架。
4.1 FOCAS库的分层结构：从硬件到应用的四个层次
FOCAS协议体系并非单一的函数集合，而是按照职责边界划分为四个清晰的层次。理解分层结构有助于开发者在不同场景下选择合适的调用方式，也便于排查通信故障。
4.1.1 核心原理：分层架构的设计思想
FOCAS的分层设计遵循了经典的“协议栈”思想，每一层只负责特定职责，层与层之间通过标准接口交互。这种设计带来的直接好处是：上层业务逻辑不依赖底层硬件细节，例如更换CNC型号或通信方式（从以太网切换到板卡）时，上层代码无需大规模修改。
| 层次 | 组件 | 职责范围 | 典型接口/函数 |
|---|---|---|---|
| L1 硬件层 | CNC 系统内置服务端 | 数据源提供、以太网/总线通信 | 端口 8193（TCP） |
| L2 通信层 | FOCAS1 / FOCAS2 | 会话管理、数据帧封装、错误码转换 | focas_connect、focas_open |
| L3 功能层 | FWLIB | 业务场景封装、数据缓存、高级API | cnc_rdaxisdata、cnc_rdmacro |
| L4 应用层 | MES/SCADA/自研平台 | 数据展示、逻辑处理、决策支持 | 数据库写入、Web API |
4.1.2 判断方法：如何选择正确的调用层次
在实际开发中，判断应该使用FOCAS1/2还是FWLIB，主要依据以下三个维度：
- 开发效率：FWLIB封装了大部分常用功能，适合快速交付；FOCAS1/2更底层，适合定制化需求。
- 性能要求：高频采集（如每50ms读取一次伺服轴位置）建议直接使用FOCAS1/2，减少封装层开销；低频业务（如每分钟读取一次状态）使用FWLIB即可。
- 硬件连接方式：以太网连接使用FOCAS1，板卡连接使用FOCAS2，两者API风格一致但底层实现不同。
4.1.3 实战场景：一个典型的车间级监控系统分层
假设某工厂需要采集20台发那科0i-MF系统的主轴负载和程序运行状态。合理的分层设计如下：
- 硬件层：每台CNC通过以太网连接到车间交换机，IP地址规划为192.168.1.101~120。
- 通信层：采集网关（工业PC）使用FOCAS1库建立与每台CNC的TCP会话，设置连接超时为3秒，重试次数为2次。
- 功能层：调用FWLIB的
cnc_rdaxisdata读取主轴负载，调用cnc_rdprogram获取当前程序名。 - 应用层：数据写入SQL Server，每5秒刷新一次看板，当负载超过90%时触发报警。
这种分层方式使得后续若增加设备数量，只需在通信层增加连接配置，无需改动上层逻辑。
4.1.4 常见误区与总结
误区2：忽略会话管理。FOCAS通信是面向连接的，长时间不发送心跳包会导致连接断开。建议每30秒发送一次空操作（
cnc_gettime）保持会话活跃。
4.2 核心组件详解：FWLIB与FOCAS1/2的职责边界
FOCAS体系中最容易混淆的就是FWLIB和FOCAS1/2的关系。本节从功能定位、API风格、错误处理三个维度进行对比。
4.2.1 核心原理：FOCAS1/2是“通信协议”，FWLIB是“功能封装”
FOCAS1/2直接对应发那科官方提供的动态链接库（Windows下为Fwlib32.dll，Linux下为libfwlib32.so），它们实现了与CNC建立连接、发送请求、接收响应的完整协议栈。而FWLIB是发那科在FOCAS1/2之上提供的一组更高级的API，它把多个底层调用组合成一个有业务含义的操作。例如，读取一个宏变量在FOCAS1/2中需要先构造请求结构体、调用cnc_rdmacro、再解析响应结构体；而在FWLIB中只需一行cnc_rdmacro(handle, macro_num, &value)。
4.2.2 对比分析：FOCAS1/2与FWLIB的关键差异
| 对比维度 | FOCAS1/2 | FWLIB |
|---|---|---|
| 定位 | 通信协议层 | 功能封装层 |
| API风格 | 面向过程，参数多，需手动管理结构体 | 面向业务，参数精简，自动处理内部逻辑 |
| 错误处理 | 返回错误码（如EW_LENGTH、EW_BUSY） | 返回统一异常，部分函数提供错误详情 |
| 性能开销 | 低，适合高频采集 | 略高，适合中低频业务 |
| 适用场景 | 定制协议、特殊数据读取、高频轮询 | 标准业务、快速开发、维护简单 |
4.2.3 实战场景：FOCAS1/2直接调用示例
以下代码展示了使用FOCAS1/2直接读取主轴负载的完整流程（C语言风格）：
#include "fwlib32.h"
ODBACT data;
short ret;
// 建立连接
ret = cnc_allclibhndl3("192.168.1.101", 8193, 10, &handle);
if (ret != EW_OK) { printf("连接失败: %d\n", ret); return -1; }
// 读取主轴负载（轴号1）
ret = cnc_rdaxisdata(handle, 1, 0, &data);
if (ret == EW_OK) {
printf("主轴负载: %d%%\n", data.actload);
} else {
printf("读取失败: %d\n", ret);
}
// 断开连接
cnc_freelibhndl(handle);而使用FWLIB时，同样的功能代码量减少约40%，且错误处理更友好。但FWLIB无法覆盖所有FOCAS1/2的底层功能，例如读取系统报警履历的原始二进制数据时，仍需直接调用FOCAS1/2。
4.2.4 常见误区与总结
4.3 通信模型与数据流：从CNC到应用端的完整链路
理解FOCAS的通信模型，关键在于掌握“请求-响应”模式、数据封装格式以及异常处理机制。本节通过一个完整的采集链路来展示数据流。
4.3.1 核心原理：基于TCP的同步请求-响应模型
FOCAS通信采用客户端-服务器模型，CNC作为服务器端，采集软件作为客户端。每次数据读取都遵循以下步骤：
- 建立连接：客户端通过
cnc_allclibhndl3发起TCP连接，指定IP、端口（默认8193）和超时时间。 - 发送请求：客户端构造请求数据包，包含功能码（如读取轴数据、读取宏变量）和参数。
- 等待响应：CNC处理请求后返回响应数据包，包含状态码和实际数据。
- 解析数据：客户端根据功能码解析响应结构体，提取所需字段。
- 断开连接：通信结束后调用
cnc_freelibhndl释放资源。
4.3.2 数据流分析：一次完整的宏变量读取过程
以读取宏变量#501为例，数据流如下：
| 步骤 | 方向 | 数据内容 | 格式 |
|---|---|---|---|
| 1. 连接请求 | 客户端→CNC | IP+端口+超时 | TCP握手 |
| 2. 会话建立 | CNC→客户端 | 句柄（handle） | 32位整数 |
| 3. 读取请求 | 客户端→CNC | 功能码+宏变量号 | 固定长度帧 |
| 4. 数据响应 | CNC→客户端 | 状态码+宏变量值 | ODBMACRO结构体 |
| 5. 断开连接 | 客户端→CNC | 释放句柄 | TCP挥手 |
4.3.3 实战场景：高频采集时的数据流优化
某汽车零部件工厂需要每100ms采集一次伺服轴位置，用于轨迹分析。如果每次采集都重新建立连接，会产生大量TCP握手开销，导致采集频率不稳定。优化方案如下：
- 长连接复用：在程序启动时建立连接，整个采集周期内保持会话，避免频繁握手。
- 批量读取：使用
cnc_rdaxisdata一次读取多个轴的数据，减少请求次数。 - 异步处理：将数据解析和存储放在独立线程，避免阻塞通信线程。
优化后，单台CNC的采集周期稳定在80~90ms，满足100ms的采集要求。若使用FWLIB的封装函数，由于内部增加了缓存和检查逻辑，采集周期会延长至120ms左右，此时必须改用FOCAS1/2直接调用。
4.3.4 常见误区与总结
4.4 通信异常处理与调试方法
在实际项目中，通信异常是开发者最常遇到的问题。本节总结常见的错误码、排查流程和调试工具。
4.4.1 核心原理：FOCAS错误码分类
FOCAS返回的错误码分为三类：连接类错误（如EW_NODATA、EW_TIMEOUT）、参数类错误（如EW_LENGTH、EW_RANGE）、状态类错误（如EW_BUSY、EW_PROT）。理解错误码的语义是快速定位问题的关键。
4.4.2 判断方法：常见错误码速查表
| 错误码 | 含义 | 常见原因 | 解决措施 |
|---|---|---|---|
| EW_OK (0) | 成功 | - | - |
| EW_NODATA (-17) | 无数据 | CNC未准备好或数据不可用 | 检查CNC运行状态 |
| EW_TIMEOUT (-18) | 超时 | 网络延迟或CNC忙 | 增加超时时间，检查网络 |
| EW_BUSY (-19) | 忙 | CNC正在处理其他请求 | 稍后重试，降低采集频率 |
| EW_LENGTH (-20) | 数据长度错误 | 请求参数长度不匹配 | 检查结构体大小 |
| EW_PROT (-21) | 协议错误 | 版本不兼容或数据帧损坏 | 检查FOCAS库版本 |
4.4.3 实战场景：排查一次“连接超时”故障
某项目在采集过程中频繁出现EW_TIMEOUT错误，导致数据中断。排查过程如下：
- 检查网络连通性：使用
ping 192.168.1.101确认网络通畅，延迟小于1ms。 - 检查端口状态：使用
telnet 192.168.1.101 8193测试端口是否开放，发现连接被拒绝。 - 检查CNC参数：登录CNC系统，确认FOCAS端口已启用（参数#11300设为1）。
- 检查防火墙：发现车间网关防火墙拦截了8193端口，添加放行规则后故障解决。
复盘经验：FOCAS连接超时80%以上是网络配置问题，而非协议本身问题。建议在项目部署前，先使用发那科官方提供的FOCAS Sample工具测试连通性，再编写业务代码。
4.4.4 常见误区与总结
FWLIB_DEBUG=1），可以输出详细的通信帧内容，便于定位问题。但在生产环境中务必关闭，否则会显著降低采集性能。
通过本章的学习，学习者应能够清晰描述FOCAS协议的四层体系结构，区分FWLIB与FOCAS1/2的适用场景，并掌握通信数据流的完整链路。在实际项目中，建议按照“先FWLIB快速验证，再FOCAS1/2深度优化”的策略推进，同时重视通信异常的排查方法，确保数据采集系统的稳定运行。