259 lines
12 KiB
Plaintext
259 lines
12 KiB
Plaintext
|
||
我会先读取两个项目的结构和已有 gmoccapy/RTCP 相关实现，确认页面、
|
||
测试入口和 LinuxCNC 参考程序的位置，
|
||
再决定需要补齐的功能和验证文档落点
|
||
|
||
|
||
当前项目已经有 gmoccapy、XYZAB/XYZAC、真实 LinuxCNC 五轴程序相关测试和文档资产。
|
||
我接下来会把现有实现与 LinuxCNC configs/sim/gmoccapy 的五轴配置、
|
||
实际 RTCP 程序和测试脚本对齐，先找出差距再补实现/验证文档。
|
||
|
||
我看到工作树已有大量未提交改动，
|
||
其中不少正好涉及本项目的 gmoccapy、RTCP、task/HAL 和测试。
|
||
我会只在必要文件上增量修改，不回退现有内容；
|
||
下一步重点收敛到 LinuxCNC 的 gmoccapy 非平凡五轴配置和 TRT/RTCP 程序。
|
||
|
||
|
||
|
||
|
||
先给出当前执行计划：
|
||
1) 提取 LinuxCNC gmoccapy 五轴基准；
|
||
2) 对照 Web 页面状态、按钮、DRO、RTCP/kins/task-HAL 数据链；
|
||
3) 补测试或小范围实现；
|
||
4) 运行验证；
|
||
5) 输出中文评价文档并按 AGENTS 规则追加过程日志。
|
||
|
||
|
||
|
||
|
||
LinuxCNC 的 gmoccapy 五轴参考不是 switchkins 版本，
|
||
而是 configs/sim/gmoccapy/non_trivial_kinematics/table-rotary-tilting/xyzac-trt.ini：
|
||
固定 xyzac-trt-kins、DISPLAY=gmoccapy、XYZAC、tool-offset/y-offset/z-offset HAL 链路，
|
||
并用 boat/impeller/test 程序验证非平凡五轴 RTCP/刀长语义。
|
||
我会把这条 gmoccapy 专属基准纳入 Web 侧验证，
|
||
而不只依赖 axis/vismach 的 M428/M429 示例。
|
||
|
||
现有测试已经覆盖 axis/vismach TRT demos 和 switchkins，
|
||
但还没有把 LinuxCNC gmoccapy/non_trivial_kinematics/table-rotary-tilting
|
||
作为单独对标对象。接下来我会补一个 gmoccapy 参考验证，
|
||
把 INI/HAL/刀表/示例程序、页面状态和 canonical 执行链打通。
|
||
|
||
|
||
为避免把“页面像 gmoccapy”误写成“功能等价”，我会用两个层面做证据：
|
||
一是 LinuxCNC gmoccapy 非平凡五轴配置的静态对标，
|
||
二是真实 .ngc 经解释器/运动学/页面状态链路的运行对标。
|
||
接下来开始补验证脚本。
|
||
|
||
这里有一个关键差异：
|
||
现有 xyzac-trt profile 主要来自 LinuxCNC axis/vismach switchkins 示例，
|
||
虽然页面是 gmoccapy shell，
|
||
但 profile 本身不是 LinuxCNC DISPLAY=gmoccapy 的非平凡五轴配置。
|
||
为了让“gmoccapy 页面功能对标 gmoccapy 五轴功能”成立，
|
||
我会补一个 gmoccapy-xyzac-trt 专用 profile 和验证链，而不是只在文档里说明。
|
||
|
||
|
||
我会保留现有 xyzac-trt/xyzbc-trt 行为，新增 gmoccapy TRT 作为第三个可运行 RTCP profile；
|
||
gmoccapy-xyzab 仍保持 trivkins 参考、不可提升为 RTCP。这样不会破坏旧测试的 profile 顺序假设时，
|
||
我会同步更新对应断言。
|
||
|
||
|
||
我先确认 vendored source manifest 是否已经包含 gmoccapy 非平凡五轴目录；
|
||
如果没有，测试可以直接读取 /home/meswork/cnc_wams/linuxcnc 作为参考，
|
||
但页面 staging 需要知道这些源文件。
|
||
|
||
我确认了一个限制：
|
||
当前 WASM vendor manifest 只包含 axis/vismach/5axis/table-rotary-tilting，
|
||
没有拷入 LinuxCNC 的 configs/sim/gmoccapy/non_trivial_kinematics。
|
||
因此我会把 gmoccapy TRT profile 的验证读取真实 /home/meswork/cnc_wams/linuxcnc 源文件，
|
||
同时让页面/Node staging 支持该来源，不把缺失 vendor manifest 误当作功能通过。
|
||
|
||
|
||
下一步我会把 LinuxCNC gmoccapy TRT 的真实配置和示例程序纳入可访问的 vendored source 清单，
|
||
这样页面 staging、Node 验证和评价文档都能引用同一批源文件。
|
||
这个改动是对现有 axis/vismach TRT source 的补充，
|
||
不会替换旧的 switchkins 测试资产。
|
||
|
||
我现在会实际落地改动：补 vendored gmoccapy TRT 源文件清单、增加 gmoccapy TRT profile、让 staging/校验识别 examples/ 源程序，并新增覆盖该 profile 的 Node 验证脚本。
|
||
|
||
|
||
|
||
|
||
由于 gmoccapy TRT 的 xyzac-trt.ini
|
||
通过 SUBROUTINE_PATH=./examples:../../macros 调用工具变更 remap，
|
||
我会把 table-rotary-tilting 和 gmoccapy/macros 两块源文件一并放入 vendor/staging 范围，
|
||
避免验证只拿到主程序而缺 remap 子程序。
|
||
|
||
已复制真实 LinuxCNC gmoccapy TRT 配置、示例程序和 gmoccapy macros 到
|
||
wasm-port/vendor/linuxcnc，接下来把这些文件加入 manifest，
|
||
并在应用代码中使用它们。
|
||
|
||
|
||
我会用脚本式追加 manifest 条目来避免手工漏项，然后用 apply_patch 修改应用源码和测试。
|
||
|
||
|
||
|
||
我还发现 parser 的“ready”标准目前按 switchkins 示例写死，会把 LinuxCNC gmoccapy
|
||
固定 xyzac-trt-kins 配置误判为缺 M428/M429/M430。
|
||
我会把 INI 校验改成两类：switchkins TRT 和 gmoccapy fixed TRT，
|
||
二者都能作为五轴 RTCP 参考，但在页面里显示不同边界。
|
||
|
||
|
||
这里的 gmoccapy TRT 固定配置还有一个语义细节：
|
||
它的 xyzac-trt-kins 没有 sparm=identityfirst，
|
||
所以 LinuxCNC 源码里 switchkins-type 0 就是 TRT/TCP，而不是 identity。
|
||
我会在 Web profile 里明确这个“固定 TRT 默认类型”，避免错误地要求 M428 才算 RTCP 开启。
|
||
|
||
|
||
一个实现细节需要小心处理：
|
||
当前 kinematics WASM 模块初始化默认和 LinuxCNC 源码一致，xyzac-trt-kins 的 type 0 是 TRT，
|
||
只有 INI 传 sparm=identityfirst 时 type 0 才变 identity。
|
||
现有 Web 的 axis/vismach profile 是通过 Web 映射把 M428/M429
|
||
语义处理成 identity/TCP；gmoccapy TRT 固定配置则应使用 type 0 TRT 默认。
|
||
|
||
我开始用补丁新增 gmoccapy-xyzac-trt profile。这个 profile
|
||
会保留 LinuxCNC 源中的 DISPLAY=gmoccapy、固定 xyzac-trt-kins、
|
||
examples/impeller-7bl-xyzac.ngc、tool-offset/y-offset/z-offset、
|
||
POSTGUI 工具/主轴绑定等对标项。
|
||
|
||
|
||
已添加 gmoccapy-xyzac-trt profile 文件。
|
||
现在继续把它接入 profile index、source reference、staging、INI 校验和默认程序选择。
|
||
|
||
|
||
我会把 source reference 中原本挂在 xyzac-trt 下的 gmoccapy TRT 条目迁移到新 profile，
|
||
并增加 generated HAL、macro remap 和源码引用，
|
||
这样文档矩阵能明确区分 axis/vismach switchkins 与 gmoccapy 非平凡五轴。
|
||
|
||
我会把 source reference 中原本挂在 xyzac-trt 下的 gmoccapy TRT 条目迁移到新 profile，
|
||
并增加 generated HAL、macro remap 和源码引用，
|
||
这样文档矩阵能明确区分 axis/vismach switchkins 与 gmoccapy 非平凡五轴。
|
||
|
||
|
||
我已完成 source map 迁移。现在修改 machine-file staging：
|
||
默认仍走 axis/vismach TRT；当 profile 是 gmoccapy-xyzac-trt 时，
|
||
自动使用 configs/sim/gmoccapy/non_trivial_kinematics/table-rotary-tilting/examples
|
||
作为真实 LinuxCNC G-code 源目录。
|
||
|
||
我还需要补齐刚才 staging 改动的底部 helper，特别是把 examples/ 归类为 demo，
|
||
并在没有传入 plan 时保持旧的 axis/vismach 默认行为。
|
||
|
||
我需要同步放宽 INI parser 的 ready 标准：gmoccapy TRT 固定配置不声明
|
||
[HALUI] M428/M429/M430，但它的 KINS=xyzac-trt-kins、XYZAC、5 joints、
|
||
tool-offset/y/z-offset 和 gmoccapy POSTGUI 才是对标依据。
|
||
|
||
|
||
我会继续同步构建脚本和默认程序选择，确保 dev 和 dist 两种运行路径都能读取 gmoccapy TRT 源文件。
|
||
|
||
|
||
我正在接入默认加载逻辑：gmoccapy TRT 的默认程序应选 impeller-7bl-xyzac.ngc，而不是按 profile id 拼 *_switchkins.ngc。同时 store 的项目目录和 source guard 也会识别 examples/ 来源。
|
||
|
||
|
||
|
||
现在修改 store 的项目目录/source guard/run preconditions。核心变化是：任何 profile 只要声明 rtcpProof=true 且有 LinuxCNC kinematics module，就可以进入运行前置条件；gmoccapy-xyzab 仍因 rtcpProof=false 被阻止。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
我注意到固定 TRT profile 需要把默认 kins 类型设为 tcp-xyzac，否则页面会把 LinuxCNC 源码中的 type 0 TRT 误显示成 identity/off。我会补一个 profile 默认 kins 辅助函数，并让 TCP button 识别 value 0 的固定 TRT。
|
||
|
||
|
||
|
||
|
||
我会先做最小默认 kins 改动，避免影响已有 switchkins profiles：只有 fixedTrtDefault profile 默认显示 TCP/RTCP on；axis/vismach 仍默认 identity/off。
|
||
|
||
|
||
|
||
|
||
我已把固定 TRT 默认 kins 的逻辑接入 store。接下来会补 profile/staging/INI 的 Node 验证脚本，然后先跑相关小测试，及时处理断言或集成问题。
|
||
|
||
|
||
我会新增专门的 verify_gmoccapy_xyzac_trt_parity，既检查 profile 静态对标，也检查 staging、INI parser、真实程序 canonical 执行和 store 状态。然后再把旧测试中 profile 列表断言更新。
|
||
|
||
|
||
|
||
|
||
我会新增的测试脚本放入 tests/node，并把它接入 npm --prefix app run smoke:node。脚本会直接跑真实 gmoccapy TRT 的 impeller/boat/test 程序，验证 canonical motion、tool-change remap staging 和页面状态。
|
||
|
||
|
||
|
||
我会修正一个刚发现的语义点：applyIniConfigToProfile 会把没有 HALUI MDI 的 gmoccapy 固定 TRT 错合并成默认 M428/M429/M430。现在改为固定 TRT 保留 profile 自己的 switchkins 类型映射。
|
||
|
||
|
||
|
||
我会调整 applyIniConfigToProfile，如果 INI 没有 [HALUI] MDI 命令，就不从 parser 推导 switchkins 类型，以 profile 的固定 TRT 映射为准。
|
||
|
||
|
||
|
||
我会把新测试加入 node smoke，并先跑新增测试与直接相关的 profile/INI/staging 测试，快速暴露集成问题。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
我现在跑新增和相关 Node 测试：profile boundary、INI runtime、machine-file staging、gmoccapy TRT parity。若出现断言失败，我会按失败点修正实现而不是放宽测试。
|
||
|
||
|
||
新增 gmoccapy TRT 测试、profile boundary、INI parser 和 machine-file staging 都已通过。接下来我会跑受影响的 sidebar/parity/run precondition/browser build 类测试，并处理可能由新 profile 顺序或 source map 变化带来的断言。
|
||
|
||
|
||
我会跑 gmoccapy_trt_project_sidebar、run_preconditions、rtcp_store 和 linuxcnc_parity_matrix，这几项最容易受 profile 列表和 source guard 改动影响。
|
||
|
||
|
||
|
||
两处失败都是集成断言而不是功能缺陷：xyzac-trt 原 profile 没显式 kinematicsModuleId，新通用 run gate 因此误判；另一个是测试还按旧 profile 列表断言。我会补显式 module id，并更新旧断言。
|
||
|
||
|
||
|
||
我已给 xyzac-trt 补上显式 kinematicsModuleId，让通用 RTCP run gate 不再把它误判为 unsupported。接下来更新旧测试的 profile 列表断言并复跑失败项。
|
||
|
||
|
||
我会复跑刚才失败的两项，并补跑新增 gmoccapy TRT 测试，确认 profile id 修复没有引入新问题。
|
||
|
||
相关失败已修复。现在我会跑完整 smoke:node，再跑 build/browser smoke；如果时间较长，我会继续报告进度。
|
||
|
||
|
||
|
||
完整 node smoke 走到 verify_gmoccapy_xyzab_profile 时只剩旧 profile 列表断言失败。这个测试应接受新增的 gmoccapy TRT profile；我会更新断言并复跑完整 node smoke。
|
||
|
||
|
||
我会复跑完整 node smoke。上一次已经覆盖到后半段，这次从头跑能确认新 profile、旧 gmoccapy XYZAB 参考和 parity 矩阵全部兼容。
|
||
|
||
|
||
|
||
完整 node smoke 已通过。接下来我会跑静态构建和浏览器 smoke，验证 dist 资产复制后 gmoccapy TRT profile 仍能读取 INI/程序，并且页面不空白。
|
||
|
||
|
||
|
||
构建已经通过，dist 资产复制正常。我会继续跑 browser smoke；如果脚本自己起本地服务就直接用它，否则我会启动项目 dev server 后验证。
|
||
|
||
|
||
|
||
|
||
我会写一份单独的中文评价报告，避免把本轮结论混在已有大文档里。报告会列明 LinuxCNC gmoccapy TRT 参考文件、对标功能、测试过程、命令输出摘要、通过/不通过边界和最终评价。
|
||
|
||
|
||
现有 browser smoke 已覆盖默认 axis/vismach TRT 源程序和 dist，但没有在浏览器里显式切到新的 gmoccapy-xyzac-trt profile。我会补一段浏览器 profile/source 验证，让 gmoccapy TRT 在实际页面中也被加载、解释和渲染。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|