63 lines
3.0 KiB
Plaintext
63 lines
3.0 KiB
Plaintext
1、分析“/home/mes123456/cnc_wams/linuxcnc”
|
||
源程序的AXIS 主界面的“急停、上电、Home、执行、暂停、单步执行”的详细调用链条和状态机制；
|
||
2、包括c++的task、motion、状态记录方式，“急停、上电、Home、执行、暂停、单步执行”的详细调用链条和状态机制；
|
||
3、linuxcnc系统的c++都是如何实现“急停、上电、Home、执行、暂停、单步执行”的功能的详细调用链条和状态机制；
|
||
4、每个按钮的可以执行的先觉条件，每个按钮执行后，如何记录当前状态，详细分析“急停、上电、Home、执行、暂停、单步执行”的详细调用链条和状态机制；
|
||
5、指导完善“/home/mes123456/cnc_wams/wasm-port”的linuxcnc的wasm
|
||
6、指导完善“/home/mes123456/cnc_wams/web-rtcp-5axis-xyzbc-trt-sim-plan”程序；
|
||
7、上面的分析结果，写入单独的文档中，指导完善项目。
|
||
|
||
我会把 working9 定义为“执行 Run 按钮主线”，但文档会保留急停、上电、Home、暂停、单步作为 Run 的前置与运行期状态链，因为这些状态直接决定执行按钮能否按 LinuxCNC 语义工作。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
我发现 wasm-port/runtime/core/linuxcnc_wrap/linuxcnc_task_hal_wasm.cpp 仍是“phase4_minimal”任务运行时，存在手写 JSON 解析和 G-code 行派生 motion 的过渡逻辑。文档会明确指出这是当前最大语义漂移风险，并给出迁移到 vendored task/motion 状态机的分层步骤。
|
||
|
||
|
||
我会先梳理仓库结构和关键入口，重点找 AXIS UI、NML command/status、task/motion 相关实现，再把分析写成独立中文文档并按要求追加过程日志。
|
||
|
||
AXIS 层已确认：按钮本身只做少量 UI 前置判断，真正状态跳转通过 linuxcnc.command() 写 NML 命令。下面我会追 emctaskmain 如何按解释器状态接收/排队/拒绝这些命令，以及 motion 如何接收 task 下发的实时命令。
|
||
|
||
task 层的核心状态已经清楚：task.state/mode/interpState/task_paused 是 GUI 可见状态，stepping/steppingWait 和 motion.traj.single_stepping 管单步。接下来补 motion 侧 EMCMOT_ENABLE/DISABLE/PAUSE/RESUME、homing 状态位和状态发布结构。
|
||
|
||
状态发布路径也已定位：task 主循环每周期读 motion 共享状态，合成 emcStatus，Python stat.poll() 直接暴露这些字段。现在我会快速检查两个目标项目当前结构和已有按钮实现，再把源码链路和改进清单写进独立文档。
|
||
|
||
目标项目已有 task/HAL WASM、Web store 和按钮验证基础，文档会把下一步重点放在“把现在的 JS 状态策略压缩成 LinuxCNC 状态机镜像、补齐 status 字段与命令队列语义”，而不是建议重写 CNC 语义。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
初步线索确认：AXIS 按钮入口在 src/emc/usr_intf/axis/scripts/axis.py 和 share/axis/tcl/axis.tcl，Python 扩展把按钮动作转换成 NML 命令，emctaskmain.cc 的状态机决定命令是否可执行。现在我会读关键函数的原始代码段并记录行号。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|