✨ feat(fanuc): 优化 J519 实时下发与飞拍起停整形

- 改为高优先级 J519 接收线程与复用缓冲区发送链路
- 增加稠密执行前的 J519 就绪重试与状态诊断
- 修正程序状态响应字段顺序与 EnableRobot 默认参数
- 为飞拍轨迹补充平滑起停时间轴与首尾整形验证
- 补充真实运行配置、报警窗口与边界对比测试
- 同步更新限值文档、分析脚本与 .NET 8 SDK 固定配置

docs/move-joint-jerk-comparison-20260505.md

@@ -7,6 +7,7 @@
 本文档固定记录以下三类证据，避免后续继续混用测试基线、旧文档结论和当前运行目录中的真实模型数据：
 
 - 当前运行目录 `.robot` 模型中的六轴基础 `velocity / acceleration / jerk`
+- 现场示教器读取到的六轴 `velocity / acceleration / jerk`
 - 当前运行目录 `RobotConfig.json` 中的 `acc_limit / jerk_limit`
 - 当前失败样本 `ActualSendJerkStats.txt` 中的逐轴实发跃度峰值
 
@@ -46,7 +47,29 @@
 - 当前运行目录中，`Joint1.jerk_base` 不是测试基线里常见的 `272.7`，而是 `224.22`。
 - 因此当前样本的 `Joint1` 生效 jerk 上限应按 `224.22 * 0.74 = 165.9228 rad/s^3` 计算。
 
-## 3. ActualSendJerkStats 的单位边界
+## 3. 示教器读取到的实际机器人限值
+
+2026-05-06 现场从机器人示教器读取到的速度、加速度与加加速度限制如下。示教器显示口径为角度制；下表同时记录换算后的弧度制，便于与 `.robot` / `RobotProfile` 中的基础限值直接对照。
+
+换算公式：
+
+- `rad = deg * π / 180`
+
+| Joint | velocity(deg/s) | velocity(rad/s) | acceleration(deg/s^2) | acceleration(rad/s^2) | jerk(deg/s^3) | jerk(rad/s^3) |
+| --- | ---: | ---: | ---: | ---: | ---: | ---: |
+| Joint1 | 370 | 6.457718 | 1541.667 | 26.907165 | 12847.223 | 224.226341 |
+| Joint2 | 310 | 5.410521 | 1291.667 | 22.543842 | 10763.889 | 187.865303 |
+| Joint3 | 410 | 7.155850 | 1708.333 | 29.816036 | 14236.111 | 248.467010 |
+| Joint4 | 550 | 9.599311 | 2291.667 | 39.997135 | 19097.223 | 333.309419 |
+| Joint5 | 545 | 9.512044 | 2270.833 | 39.633513 | 18923.611 | 330.279318 |
+| Joint6 | 1000 | 17.453293 | 4166.667 | 72.722058 | 34722.223 | 606.017115 |
+
+这组数据的含义：
+
+- 示教器读取值与当前运行 `.robot` 中的 `velocity_base / acceleration_base / jerk_base` 基本一致，可作为实际机器人基础限值证据。
+- 它还没有叠加当前 `RobotConfig.json` 的 `acc_limit = 0.74` 与 `jerk_limit = 0.74`；若用于本次失败样本比较，仍应使用第 2 节中的 `acc_eff / jerk_eff` 作为生效上限。
+
+## 4. ActualSendJerkStats 的单位边界
 
 `ActualSendJerkStats.txt` 的真实输入不是弧度，而是 J519 下发用的角度制关节目标：
 
@@ -60,7 +83,7 @@
 - 若要与 `.robot` / `RobotProfile` 中的 jerk limit 比较，需要先换算为 `rad/s^3`
 - 换算公式：`jerk_rad = jerk_deg * π / 180`
 
-## 4. 全文件逐轴最大跃度对比
+## 5. 全文件逐轴最大跃度对比
 
 扫描整份 `ActualSendJerkStats.txt` 后，各轴绝对值最大跃度如下：
 
@@ -79,7 +102,7 @@
 - 其余 5 个轴即使取全文件峰值，也远低于各自当前生效 jerk limit。
 - 当前样本本质上是一个“J1 主导”的跃度问题，而不是六轴普遍同时逼近上限。
 
-## 5. 报警窗口逐轴对比
+## 6. 报警窗口逐轴对比
 
 结合抓包与 J519 序号，报警前最后一个关键窗口是：
 
@@ -104,7 +127,7 @@
 - `Joint1` 在报警窗口内已经达到当前生效 jerk limit 的 `2.1454x`
 - 其余 5 轴在同一窗口仍远低于生效 jerk 上限
 
-## 6. 报警窗口与全局峰值窗口的关系
+## 7. 报警窗口与全局峰值窗口的关系
 
 本次样本不能简单理解为“最大峰值出现的位置就是首次报警位置”。
 
@@ -118,11 +141,12 @@
 1. 机器人第一次进入异常态时，`Joint1` 已经在 `0.296 -> 0.304s` 超限约 `2.15x`
 2. 即便忽略第一次报警，后续轨迹中仍存在更高的 J1 跃度峰值，说明当前 `MoveJoint` 临时轨迹整体都偏激，不只是单个孤立点异常
 
-## 7. 当前可落地的结论
+## 8. 当前可落地的结论
 
 基于当前运行目录的真实模型、配置和实发跃度文件，本次失败样本可以先固定为下面这组结论：
 
 - 当前运行模型 `Joint1.jerk_base = 224.22`，不是 `272.7`
+- 现场示教器读取到的 `Joint1.jerk = 12847.223 deg/s^3 = 224.226341 rad/s^3`，与当前运行模型基础值一致
 - 当前样本 `jerk_limit = 0.74`，所以 `Joint1.jerk_eff = 165.9228 rad/s^3`
 - `ActualSendJerkStats.txt` 需要按 `deg/s^3` 理解，再换算成 `rad/s^3` 后与模型 jerk limit 对比
 - 无论看报警窗口还是看全文件峰值，越限主体都只有 `Joint1`