简介面向法兰克数控系统二次开发的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.dllLinux 下对应 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不妨也用这个节奏先小步走通再铺开做省下的全是返工的工时。本文还有配套的精品资源点击获取 FOCAS2开发包：打通发那科CNC数据采集与设备联网的关键接口
简介面向法兰克数控系统二次开发的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.dllLinux 下对应 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不妨也用这个节奏先小步走通再铺开做省下的全是返工的工时。本文还有配套的精品资源点击获取