fix: verify run path with 50ms screenshots

备忘/备忘测试仿真界面西操作按钮的功能.txt

@@ -0,0 +1,100 @@
+1、解除急停 好用
+2、上电   好用
+3、HOME 数据变化了，刀具实际
+
+
+
+/home/mes123456/cnc_wams/web-rtcp-5axis-xyzbc-trt-sim-plan
+
+
+增加一个Auto/Manual切换按钮
+
+
+我会按你说的方式重新做一次“完整执行过程”的 50ms 连续截图，不只截前 2 秒；
+同时记录每帧的 task/HAL 轴位、TCP、canvas toolhead、sampleIndex 和截图实际时间间隔。
+然后我用这组数据定位刀具路径为什么不对，再修渲染/路径映射。
+
+执行过程，每隔50毫秒全部截屏，刀具运动路径不正确
+
+
+我会按你说的方式重新做一次“完整执行过程”的 50ms 连续截图，不只截前 2 秒；同时记录每帧的 task/HAL 轴位、TCP、canvas toolhead、sampleIndex 和截图实际时间间隔。然后我用这组数据定位刀具路径为什么不对，再修渲染/路径映射。
+
+完整 50ms 全过程截图已经完成，证据目录是 working/screenshots/run-full-50ms-toolpath-20260703T202207Z/，共 71 帧和 samples.json。采样暴露了更明确的问题：执行很快完成，但 activeLine/motionIndex 只跳了 0 -> 1 -> 28，中间路径没有按 29 段连续映射到 UI/canvas，所以刀具路径显示会不正确。我继续查 task/HAL 状态里的 motion 进度和前端 sample 映射。
+
+我看了完整样本，问题不只是截图帧数：task/HAL 的 ui.axisPose 在连续推进，但前端把刀具位置混用了旧的 tcpPose/预览 sample，因此 toolhead 和最终刀具路径会偏离实时轴位，尤其 B/C 切换后更明显。我会把 task/HAL 路径下的刀具渲染基准改成实时 task/HAL 反馈轴位，并让 sampleIndex 按 task/HAL servo cycle 推进，避免路径只跳 0 -> 1 -> 1293。
+
+
+关键点找到了：task/HAL 返回的是关节/轴命令位置，但 setState() 随后又触发 LinuxCNC kinematics frame，把 axisPose 改写为 forward kinematics 后的 TCP pose，导致 axisPose、tcpPose、toolhead 混在一起。刀具路径应由 task/HAL 实时轴位驱动，不应被 kinematics refresh 改写。我要在 task/HAL 状态补丁中保留 raw joint/axis pose，并让渲染用 raw task/HAL 位置；同时让 sampleIndex 按 servoCycle 比例推进，避免路径只跳几个点。
+
+Read a fileRead store.js
+
+我会先修最直接的路径错误：task/HAL 路径下的 tcp 不再取被 kinematics 改写后的旧 state.tcpPose，而是直接由当前 task/HAL 实时轴位生成；同时用“最近轴位”在预览 samples 中找当前 sampleIndex，让执行路径沿着真实 helix/运动轨迹推进，而不是卡在线号。
+
+完整截图还在执行中；这次会跑到程序完成或最多 1500 帧。由于每帧都要保存全页 PNG，实际间隔会大于 50ms，我会在 samples.json 里记录实际间隔和截图耗时。
+
+还在截全流程，说明修正后不再几秒内跳到完成，程序执行过程被完整展开了。继续等待完成后我会分析最终 sampleIndex、toolhead bounds 和帧目录。
+
+全量 50ms 截图仍在跑，当前没有报错。这个时长是预期内的：全页截图本身平均会超过 50ms，所以“每 50ms目标采样”会记录实际间隔。
+
+这次完整 1500 帧反而暴露了一个新问题：点击 Run 后只完成了 remap motion 生成，状态一直 idle，没有进入 task/HAL PLAN_RUN。也就是说我刚才的 sampleIndex 修正引入了/暴露了 Run 启动链路卡在 interpreter 完成后的问题。我先用短脚本复现状态，再修 RUN_FROM_OPERATOR 的异步等待链路。
+
+短链路仍卡在 remap 完成后，说明卡点在装载/重建 taskHal session 之前或其中。下一步我直接打印 taskHalSession.programPath 与期望程序路径，确认是不是 session mismatch 触发了重建并卡住。
+
+
+我需要精确确认 async 卡在哪一步。我会在 RUN_FROM_OPERATOR 的关键阶段写入 operatorMessage：motion ready、session check、motion plan loading、motion plan loaded、plan run command sending。这样短复现会直接显示卡点，而不是只有旧消息。
+
+
+
+
+我会先把路径索引映射修正为按任务/HAL实际轴位姿向前全局匹配，然后重新构建并做 50ms 全过程截图验证。现有证据已经说明问题不是按钮事件，而是运行时轴位姿到预览路径采样点的映射跳点。
+
+
+
+当前只看到 4174 静态服务器还在，没有遗留的 Playwright 或 Chromium 进程。接下来直接改采样映射函数，让截图中的刀具轨迹用任务/HAL反馈的实际轴位姿连续推进。
+
+
+我会扩大并约束路径采样搜索：从当前采样点只向前匹配实际轴位姿，避免按 G-code 行号在重复行之间跳跃；同时保留单调前进，防止回退造成轨迹抖动。
+
+代码已改完，下一步重新构建静态包，让 4174 端口上的页面加载新的 dist 文件，然后用 Playwright 按“上电 -> Home All -> Run”采集完整过程。
+
+
+
+为了避免只靠状态断言，我会用真实页面点击控件，并在点击 Run 前后按 50ms 目标间隔保存连续截图和状态样本；脚本同时记录按钮状态、运行状态、轴位姿、刀具 TCP 和画布数据。
+
+
+现在开始实际浏览器验证。因为浏览器截图本身有耗时，脚本会以 50ms 为目标节拍保存每一张图，并在 samples.json 里记录每张图的真实时间间隔，便于判断是否有漏采或路径跳变。
+
+
+这台环境的根目录没有 playwright 包，我会改用项目 app/node_modules 里的依赖来跑同一套截图脚本。
+
+
+
+系统 Chrome 路径可用：/usr/bin/google-chrome。我会用这个路径重新跑完整截图验证。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+