机器人采集是什么，用在哪些场合
指的是从工业机器人控制器里读取运行数据， 包括运行/暂停/停止状态、当前程序与行号、 伺服上电与使能状态、报警与故障代码、关节与法兰位姿、速度倍率、 各轴电流或力矩、循环计数与节拍、工具与工件坐标系编号等。 用途集中在几类：整线稼动率与节拍统计、 焊接/涂胶/搬运工位的过程追溯、 机器人本体的健康监测（力矩趋势、减速机温升）、 以及产线看板上的实时状态显示。
现场最常见的四家是 KUKA、ABB、安川与 UR（优傲），
它们的数据接口机制彼此完全不同，
不像 PLC 那样有一个 Modbus 作为公共分母。
敏洽 SCADA 数采软件
对应提供 kuka_krl、abb_rws、
yaskawa_motocom、ur_rtde 四个驱动，
FANUC 机器人走 fanuc_focas（见
FANUC FOCAS 数据采集）。
实际会遇到的几个坑
1. 四家的机制不同，方案不能照搬
这是做多品牌产线时最容易低估的一点。 KUKA 的做法通常需要机器人侧的 KRL 程序配合—— 把要外发的数据写到约定的接口变量或通信区，采集侧再读， 也就是说这条路绕不开动机器人程序，需要机器人工程师参与。 ABB 的 RWS 是控制器内置的 HTTP 服务， 用类似 REST 的方式访问 RAPID 变量、I/O 信号、控制器状态与事件日志， 还能订阅变化，采集侧不必改机器人程序，这是它比较友好的地方。 安川走 MotoCOM 类接口，按功能调用读变量、位置、状态与报警。 UR 的 RTDE 是订阅式实时流，先声明要哪些字段， 之后控制器按周期持续推送。 同一个「读机器人状态」的需求，在四家身上的工作量与依赖方完全不同， 报价时必须分开算。
2. 需要改机器人程序的方案，排期取决于别人
凡是需要在机器人侧写代码配合的（KUKA 尤其典型，安川部分场景也会）， 实际排期就卡在机器人工程师的档期和客户的程序变更审批上。 机器人程序是经过验证的生产程序，改动通常要走变更流程、 重新试运行确认安全与节拍。 这一段时间不在软件开发工作量里，但会实实在在拖长项目周期。 方案阶段就要把它作为独立的前置条件列出来， 注明由哪一方负责、什么时候完成。
3. 选装通信选项没开通
和数控系统一样，机器人控制器的通信能力也常常是选装项。 现场表现是：能连上但某类数据读不到，或者接口服务根本没启用。 这类问题在方案阶段无法靠猜解决，必须让客户或机器人集成商 给出控制器当前已开通选项的清单。 拿不到清单就带设备去现场做一次连通性验证， 不要在合同里承诺具体数据项能读到。 UR 的 RTDE 属于标准能力，这方面确认成本最低。
4. 采集把控制器 CPU 拖慢，影响节拍
机器人控制器要优先保证运动控制的实时性， 通信是次要任务。轮询过密、一次请求的数据项过多、 或者在机器人程序的高速循环里插通信指令， 都可能造成程序执行变慢、界面卡顿甚至节拍波动。 这类问题在生产线上是严重问题，客户会直接要求关掉采集。 稳妥的做法是：采集频率必须可配置， 按慢变量 1 秒、快变量按需的原则起步， 上线后观察节拍数据有无变化再调整； 需要高频数据时优先选支持流式推送的机制（如 RTDE）， 而不是把轮询频率往上堆。
5. 「程序号」和「当前工件」经常对不上
做追溯时需要知道每个循环加工的是哪个工件， 而机器人能给的通常只是程序名与行号。 程序名只代表工艺路径，不代表工件身份。 要把两者关联起来，必须有一个环节把工件标识（条码、RFID、料盘位置） 与机器人的一次循环绑定—— 要么由 PLC 统一管理并在循环开始时写入一个可读的变量， 要么由机器人程序自己接收上位机下发的工件号。 这一点属于接口约定， 不定清楚的话采集回来的数据是一串「某个程序跑了多少次」， 没法用于追溯。
6. 报警代码需要一张对照表
各家的报警号体系不同，而且同一个号在不同控制器版本上的文本可能有差异。 采集侧只存报警号，看板上显示不出来人能看懂的内容。 需要向机器人方要一份报警号与中文含义的对照表， 或者从控制器接口把报警文本一并读出来（能读文本的优先读文本）。 另外要注意区分「报警」和「提示/警告」—— 两者混在一起统计，故障停机时长会算得偏大， 口径相关的处理见 OEE 怎么算才不被终端客户挑战。
接入方式与硬件条件
| 品牌 | 驱动 | 机制与前置条件 |
|---|---|---|
| KUKA | kuka_krl | 需机器人侧 KRL 程序配合把数据写到约定接口区；依赖控制器已开通的以太网通信选项；需机器人工程师参与并走程序变更流程 |
| ABB | abb_rws | 控制器内置 HTTP 服务，按 REST 风格访问 RAPID 变量、I/O、状态与事件日志，支持订阅；一般不需改机器人程序；需控制器账号与网络可达 |
| 安川 | yaskawa_motocom | MotoCOM 类接口按功能调用读变量、位置、状态与报警；部分数据项依赖控制器选项，需逐项确认 |
| UR | ur_rtde | RTDE 实时数据流，先订阅字段再按周期接收；标准功能无需选装；适合高频关节与力矩数据 |
| FANUC 机器人 | fanuc_focas | 走 FOCAS，判断顺序见 FANUC FOCAS 数据采集 |
| 网络 | — | 网线接到控制器以太网口，需与采集机在同一网段或路由可达；IP 与端口由客户网络管理方分配 |
| 连接数 | — | 控制器并发连接数有限，若已被既有系统占用需先确认；建议一台机器人只保留一路采集，由采集侧分发给多个上层系统 |
硬件上不需要特殊设备，一根网线加交换机端口即可。 真正的前置条件是三份信息：控制器型号与软件版本、 已开通的通信选项清单、以及需要的数据项清单。 这三份齐了才能判断可行性与工作量， 缺任何一份都只能给出带条件的结论。
相关交付情况
多品牌混线的产线，敏洽的做法是在采集层把品牌差异吃掉： 各家驱动往上暴露统一的数据模型（状态、程序、报警、位姿、计数）， 看板与上层系统只对接这套统一模型， 这样后面新增或更换机器人品牌时，改动限制在驱动配置层。 如果每个品牌都单独往 MES 里做一套接口， 产线一改型就要动上层，维护成本会持续累积。
需要改机器人程序的品牌，建议把这部分工作明确划给机器人集成商或客户方， 并在接口文档里写清变量名、数据类型与刷新时机， 切分方式见 上位机软件外包怎么切分。 更多交付情况见 案例中心。
常见问题
有具体设备清单或工件样品，可以直接给判断
提供设备型号、PLC 品牌与需要采集的数据项，或提供被检工件照片与精度要求，敏洽可先给出可行性判断与硬件前置条件，再谈软件工作量与报价。