4. 节拍测量与数据采集

节拍优化最怕“凭感觉”。现场常说“这个工位慢”，但慢多少、慢在哪个动作、是程序等待还是外部设备拖后腿，必须靠数据说话。节拍测量与数据采集的任务，就是把一个循环拆成可量化、可复现、可对比的时间片段，并定位真正的瓶颈工位。本节围绕四类手段展开：UR 日志、示波器与数字 IO、外部传感器、上位机软件工具，并给出可落地的采集与判读方法。

一、先定义测量口径，再谈数据

在采集之前必须统一口径，否则不同人测出的节拍无法比较。建议明确以下定义：

• 循环起点：以某个稳定事件为基准，例如主程序 Wait 结束、机器人开始向第一个目标点运动的瞬间，或 PLC 发出“允许启动”信号的上升沿。
• 循环终点：与起点同源的事件下一次出现，例如同一数字输出再次置位。用同源事件可避免累计漂移。
• 节拍（Cycle Time）：起点到终点的时间差，单位秒，保留三位小数。
• 瓶颈工位：在整线中节拍最长、或波动最大、或造成上下游等待的工位。

参照约定：本文所有时间轴以“循环起点为 0 s、向右为正”表示，信号上升沿表示事件发生。若改用 PLC 扫描周期为基准，需在记录中注明，全文保持一致。

二、UR 日志：最轻量的第一手数据

UR 控制器自带日志与示教器上的时间信息，是零成本起点。常用做法有三种：

1. 程序内打点：在关键动作前后插入 write 或通过 set_digital_out 翻转一个空闲输出，配合上位机记录时间戳。例如在抓取前 set_digital_out(7, True)，放置后 set_digital_out(7, False)，用外部记录设备读取该 IO 的脉宽，即为“抓取—放置”段耗时。
2. Polyscope 日志导出：在示教器“日志”中导出运行日志，可看到程序启动、停止、保护性停止等事件时间。它适合判断“是否发生异常停机”，但分辨率通常不足以拆分单个动作。
3. RTDE / Dashboard 接口：通过 RTDE 以约 125 Hz 读取 runtime_state、actual_TCP_pose、actual_digital_input_bits 等字段，可重建轨迹与 IO 时序。这是做精细节拍分析最实用的 UR 原生通道。

示例：用 RTDE 记录 actual_TCP_speed，当速度由 0 变为大于 5 mm/s 时记为运动开始，回到 0 记为运动结束。把一次循环内所有“运动段”和“等待段”按时间排列，就能看出等待占比。若某循环总节拍 12.4 s，其中运动合计 7.1 s、等待合计 5.3 s，则优化重点应先放在等待，而不是盲目提高关节速度。

三、示波器与数字 IO：看清信号级时序

当瓶颈涉及外部设备（气缸、夹爪、PLC、安全门）时，UR 日志往往看不到对方何时响应。此时用示波器或多通道逻辑分析仪同时抓取机器人输出、外部传感器输入和 PLC 使能信号，能直接暴露“谁在等谁”。

接线要点：示波器探头地与被测系统共地；数字通道阈值按 24 V 系统选择合适衰减或使用光耦隔离；触发方式选“机器人启动输出上升沿”，保证每次抓到的是同一段循环。典型判读：机器人发出“夹爪闭合”命令后，夹爪到位传感器延迟 0.8 s 才变高，说明夹爪动作本身是瓶颈；若传感器很快变高，但机器人 2 s 后才继续运动，则瓶颈在程序等待或通信轮询。

四、外部传感器：把“看不见的动作”变成电信号

外部传感器用于捕捉机器人本体无法感知的事件，常见有：

• 光电/接近开关：检测工件是否到达、托盘是否到位。安装在工位入口，输出接到 PLC 或采集卡。
• 压力开关：判断夹爪是否真正夹紧，避免“命令已发但未夹住”造成的隐性等待。
• 电流互感器：夹在电机或气缸电磁阀回路上，通过电流上升沿判断执行器实际启动时刻。
• 编码器/激光测距：用于测量输送线速度或工件位置，换算成时间。

采集时建议所有传感器与机器人 IO 共用同一时间基准。若传感器接入 PLC，则记录 PLC 时间戳；若接入独立采集卡，则用机器人启动输出作为同步触发，把两路数据对齐到同一 0 点。否则“机器人等了 1 s”和“传感器晚了 1 s”会互相混淆。

五、软件工具：把原始数据变成节拍报表

UR 生态中常用工具包括：

• RTDE 客户端：Python 或 C++ 编写，按固定频率记录字段并写入 CSV，适合做长期节拍统计。
• URCap 与示教器 Trace：部分版本支持轨迹跟踪，可回放运动段耗时。
• 外部 MES/SCADA：通过 OPC UA 或 Modbus 采集工位状态，生成班次节拍趋势。
• 通用分析工具：Excel、Python pandas、Grafana，用于计算均值、P95、标准差和瓶颈排名。

示例采集脚本片段（Python + RTDE，仅示意字段与记录方式）：

import rtde_receive, csv, time
r = rtde_receive.RTDEReceiveInterface("192.168.1.10")
with open("cycle.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["t", "tcp_speed", "do_bits", "di_bits"])
    t0 = time.time()
    while time.time() - t0 < 60:
        w.writerow([round(time.time()-t0, 3),
                    round(r.getActualTCPSpeed()[0], 2),
                    r.getActualDigitalOutputBits(),
                    r.getActualDigitalInputBits()])
        time.sleep(0.008)

采集 60 s 后，用 pandas 按“启动输出上升沿”切分循环，计算每段耗时。若某工位 20 个循环的节拍为 12.1、12.3、12.2、18.7、12.4……则 18.7 s 是异常值，应回看该循环的 IO 时序，判断是否发生夹爪未到位或安全门短暂触发。

六、瓶颈工位判定与采集检查表

判定瓶颈不能只看平均值。建议同时看三个指标：平均节拍、P95 节拍、等待时间占比。平均节拍最长的是“常态瓶颈”；P95 明显偏高的是“波动瓶颈”；等待占比最高的是“隐性瓶颈”。三者可能不是同一工位，优化顺序应优先处理等待占比最高的那个。

完成本节采集后，你应能回答三个问题：这个工位的真实节拍是多少？时间花在运动还是等待？等待是机器人自身、程序逻辑还是外部设备造成的？带着这三组数据进入下一阶段的优化，才能把节拍改进从“试参数”变成“有依据的工程决策”。