链路测速台 · DCU 总线吞吐取证

满帧 236B = 等效电机 OTA 0xD1 数据节奏；载荷 0 = 纯握手往返。
判读：失败必须为 0；「往返 最快」是链路物理极限周期；「调度开销 平均」是固件自己量的事件驱动唤醒损耗， 「SPI 事务 平均」才是纯总线时间；下面五段拆解告诉你时间花在提交/发送/等应答/读响应/唤醒哪一段。
设备无应答时最多等「超时」就自行判失败，按钮不会永久卡在等待态。

热改周期走 /api/motor/period（循环每拍重读的变量，全程喂狗不断流，随时可调、可反复调）。 低于 1ms 档后端自动用自旋节拍，会占满一个 CPU 核；从站固件修好前别低于 1ms —— 实测 0.25 / 0.125ms 档 GD32 顶到 99.5%，CAN 到帧率 λ 从 4000/s 塌到 149/s（瓶颈在从站不在主站， 只看主站达成率会整条看漏）。

判读：达成率 < 100% = 节拍被软件拖住；λ ÷ 实测Hz = 每拍到达几帧 CAN（当前 1ms 档实测 6 帧/拍）。
drop 不判好坏：它是段 1/段 3 那个"最近一帧"单格被未取先覆的次数， 而单格每拍只能发布 1 帧；且自增点在 STATUS 过滤之前（ethercat_can_bridge.cpp:398 对 :435），所以每拍到的 6 帧全算进来 → 恒等于 λ − 实测Hz，零独立信息量。 这些帧并没有丢：STATUS 由段 2 按槽常驻上报，其余进段 4 覆盖窗口（实测 lost/OVF 均 0）。 drop 哪天才有权报警：让只走单格的帧（版本/节点应答）承担可靠投递时。
真丢帧逐层看：① CAN 控制器 err/TEC/REC；② CAN 软件 RX 队列满（深度 16）的 rx_drop_count —— 只在 ESP32 /can/feedback 有，过程数据里没有； ③ 段 4 覆盖窗口 主站侧按 seq 空洞算的 rx_batch.lost（step/2−1， 发布值恒为偶数，按 step−1 会把每帧虚报成丢 1 个）；④ 段 4 从站侧未取先覆 rx_batch.pending（= OVF，与 ③ 是两个独立仪表，正常应当同步增长）； ⑤ CAN 取帧撕裂 rx_torn。③④ 是本页 10Hz 抽样看到的单拍值，只能当下界。 撕裂 / 重入是饱和计数（到 65535 停），封顶时只能报下界。

「速度参考」= RT_Velocity，是内部斜坡参考值而非实测转速， 不能拿去回答"三轴实际是否同步"。InitStatus 显示 — 表示这条链路没送 B32-35 —— 补 0 会把"无数据"显示成"初始化正常"。

同一 ID + 同一载荷出现两次不是重复显示：主站已按每槽 seq 去重，同一帧不会报第二次。 实测 120 个窗口快照里「同 ID 且 seq 相同」0 次、「同 ID 但 seq 不同」240 次 —— 那是两帧真的各到达一次， 只是电机空闲时 CONFIG 回报的 24B 逐字节相同，肉眼看一模一样。看下面槽表的 seq 列即可分辨。
"前面像少了一帧"也不是丢帧：① 主站每拍只把 seq 比上次大的槽交给上层，上一拍已经交过的帧 仍躺在窗口里（就是末列的"否"），但不会再进上面的表；② 页面 10Hz 采样、PDO 1kHz，两次采样之间约 100 拍的窗口内容已被覆盖，看不见（所以"样本数"只占全量约 0.8%，全量看 λ 那张卡）。 本表能看到的丢帧判据只有两个：seq 空洞（主站侧）与 OVF（从站侧）， 上面 pill 里实时显示，实测同为 0；本表看不到的还有三层 —— CAN 控制器 err/TEC/REC、 GD32 软件 RX 队列满丢（深度 16，只在 ESP32 /can/feedback 有）、CAN 取帧撕裂 rx_torn。逐层对账跑 scripts/can_bridge_reconcile.py。
长帧（CONFIG 24B / 版本应答）在 8B 短快照里会被截断，所以后端另开 state.xrx 长帧槽， 逐字节的真凭实据在下面第 ③ 区的原始窗口里。

扫描逐档下发 /api/motor/period（热改，不停循环），每档采完回读 period_ms 确认生效 —— 不一致就是被别处的 localStorage 或另一个标签页劫持了，该档标红而不是照单收下。 结束（含中止/异常）必把周期恢复成扫描前的原值并回读校验。 低档位有把从站打满的风险（λ 塌陷、从站停报），页内不做"帮你自动试到崩"。
每档驻留要大于节拍环容量 2048×周期（4ms 档 ≈8.2s、1ms 档 ≈2.05s），否则环里还是上一档的旧节拍， 页内会直接标注"本档抖动不可信"而不是给你个看着像样的 p50。