 cbb
|
979da72181
|
refactor: 入口提到根目录, 代码收进 src/
上一版把入口塞进 launch/、代码摊在根目录, 正好反了: 双击入口该第一眼看到,
实现细节该收起来。现在:
根目录 5 个 .bat/.vbs 入口 + README + requirements
src/ ecat_server / ecat_tool / ecat_flash_eeprom / test_motor_backend
src/web 前端资源 src/diag 独立诊断脚本
启动器改为 cd 进 %~dp0src 再跑(vbs 用 CurrentDirectory = base & "\src"),
工作目录落在 src 才能让 tool→flash_eeprom、test→server 的 import 解析到。
ecat_server.py 的 BASE_DIR 取自 __file__, 与 src/web 仍是同层父子关系,
_STATIC_MAP 和窗口模式的子进程 spawn 都无需改动。
.gitignore 补 sii.json / *.sii / eeprom_*.bin —— eeprom read --out 的导出
产物, 属运行结果不该入库。
验证: 7 个 py 全编译通过; test_motor_backend 8 项全通过; ecat.bat 与
run_scan.bat 实跑列出适配器; 服务起后 4 条静态路由 200 且 MIME 正确;
Edge headless 渲染主页与 motor 页, CSS 294 规则、9 节点样式生效, 零加载
失败零 JS 异常; bat 的 %~dp0 与 vbs 的 GetParentFolderName 实测均落在
项目根, src/ 下五个目标文件全部命中。
|
2026-09-03 22:27:23 +08:00 |
|
|
cbb
|
fc9e8f34e5
|
diag: 加邮箱楔死探针三件套, 移除 _repro_hang.py
_probe_wedge.py 逐环节定位死点: A 写 SM0 的 WKC → B 0x220 bit0 是否置位
→ C SSC 是否清事件并置 SM1 就绪 → D SM1 是否滞留旧响应,
用于区分 ESC 硬件楔死与 SSC 软件死循环。
_probe_wedge2.py 按真实邮箱协议走: 查写邮箱空 → 写满 256B → 验事件/响应。
_probe_stuck.py 验"SM1 响应滞留 → 邮箱死锁"假说: 复现失败 → 手动读走 SM1
清 bit3 → 再读是否恢复。若恢复则主站侧可自愈。
_repro_hang.py 的闪退成因已定位(见 a1ec486, config_map 撞楔死邮箱), 且规避
已内建到 op/start 入口, 该复现脚本失去用途, 删除。
README 同步脚本清单, 并记下 SM = 0x0800 + 8n 这个易错点。
.gitignore 排除 _analyze_log.py(硬编码已失效的临时日志路径)。
|
2026-09-03 02:36:07 +08:00 |
|