|
@@ -74,3 +74,23 @@
|
|
|
- 待用户回头确认：★**确认 D12 是否仅指"自动对焦阶段"(=我的方案B,已满足) 还是要连胚胎拍照阶段也迁本地(=方案A,需改ccdThreadFun且要先解决层对称语义对齐+管理端兼容,风险高)。** 默认按方案B继续,你说要方案A我再做。
|
|
- 待用户回头确认：★**确认 D12 是否仅指"自动对焦阶段"(=我的方案B,已满足) 还是要连胚胎拍照阶段也迁本地(=方案A,需改ccdThreadFun且要先解决层对称语义对齐+管理端兼容,风险高)。** 默认按方案B继续,你说要方案A我再做。
|
|
|
- 附:自动对焦阶段那段"绕FocusZ再拍N层capture"在去评分后可能部分变冗余(旧评分链遗留),属L1清理范畴,本次未动,留观察。
|
|
- 附:自动对焦阶段那段"绕FocusZ再拍N层capture"在去评分后可能部分变冗余(旧评分链遗留),属L1清理范畴,本次未动,留观察。
|
|
|
|
|
|
|
|
|
|
+#### [环境·阻塞] ★operate.exe(PID20268,32K)卡死无法清除→operate侧编译硬阻塞 — 2026-06-25
|
|
|
|
|
+- 情况：`ivf_tl_Operate.exe` PID20268 仅 32K 内存(=崩溃/挂起僵尸,真UI是几百MB),锁着 operate DLL。`taskkill /F` 普通态拒绝访问;**提权 taskkill /F 也杀不掉**(进程仍在)——典型"卡在内核/驱动不可中断调用"的僵尸(疑当年崩在串口/相机驱动),通常只能**重启机器**才清。
|
|
|
|
|
+- 决策/处理：**不自主重启真机**(会中断 control.exe+硬件+在培养胚胎,风险过大,超出"跑测试"授权)。因此 operate sln 编译硬阻塞 → **Task 3.4(调试页UI重构)/3.5(保存范围)只能写代码、无法编译验证**;Phase 5 另需真机硬件。
|
|
|
|
|
+- 影响面/闭环核对：control 侧/Java/管理端全部已编译验证通过(不受此阻塞);仅 operate.exe 锁的 operate 工程编译受阻。
|
|
|
|
|
+- 待用户回头确认/处理：★**需要你(或现场)在合适时机重启该真机一次,清掉卡死的 operate.exe**,之后 operate 侧代码(3.4/3.5)即可 Release 编译 + 真机联调。重启前 operate 本就是死的(32K),重启只清僵尸、不丢功能(新构建会更好)。
|
|
|
|
|
+- 我接下来：仍按 goal 把 3.4/3.5 的代码写出来(功能版,严格照现有 HouseDebugPageViewModel/DebugSessionClient/新 CalibrationClient 范式),提交时标注"compile-pending:operate.exe 卡死待重启",把开发工作推到"只差编译/真机验证"。
|
|
|
|
|
+
|
|
|
|
|
+#### [环境·突破] ★绕过卡死operate.exe做编译验证：-o 重定向输出 — 2026-06-25
|
|
|
|
|
+- 情况：operate.exe 卡死锁的是 **bin 里已加载的 DLL**;`dotnet build` 默认要覆盖 bin→MSB3021。
|
|
|
|
|
+- 突破：`dotnet build ivf_tl_Operate.sln -c Release -o /tmp/opbuild_verify`——**输出重定向到临时目录**,避开被锁的 bin,obj(中间产物)不被锁→**编译成功 0 错**。
|
|
|
|
|
+- 决策/处理：**operate.exe 锁不再是编译阻塞**。3.4/3.5(commit 6e57d04)及后续 operate 改动均用此法编译验证(`-o /tmp/opbuild_verify`)。注意:这只验证"能编译",**真机运行/界面/联调仍需重启清僵尸后跑真 operate**(Phase 5)。
|
|
|
|
|
+- 影响面/闭环核对：3.4/3.5 从"compile-pending"升级为"compile-verified 0错"。
|
|
|
|
|
+- 待用户回头确认：合适时机仍建议重启真机清卡死 operate.exe,以便真 operate 运行联调(非编译需要)。
|
|
|
|
|
+
|
|
|
|
|
+#### [Task 3.4] ★重大发现：operate进程HAL是空壳,手动命令真机失效需切CommandAsync — 2026-06-25
|
|
|
|
|
+- 情况：子代理查实——**只有 control 进程 ScanDevices 持真硬件;operate 进程 `HardwareAccessLayer.Instance` 是空壳**(从不 ScanDevices)。故调试页旧"operate 本地 gate.Acquire 拿 Serial/Cam"在真机必 null、`if(Serial==null)return` 早退=**现有调试页硬件路径从没真工作过**(既存问题,非本次引入)。真正能借硬件的唯一入口=control 的 HTTP `/debug/*`。`CurrentSessionId` 字段早声明但全库无赋值点。
|
|
|
|
|
+- 决策/处理：3.4 已把 acquire 经 DebugSessionClient(`/debug/acquire`)前移、建立 sessionId、接通 CalibrationClient(标定走 HTTP 协作=对的)。**但手动电机/光源命令仍走进程内 `Serial.*Wait()`(真机 null)→ 真机失效**。D7"保留手动功能"要真闭环,**必须把手动命令切到 `_debugClient.CommandAsync(op,args)`**(control 的 /debug/command 的 DebugSessionManager.Execute 已覆盖全部 op:Vertical/Horizontal Move/Reset/Forward/Backward、Write* EEPROM、Led/阀/曝光等)。→ 已作为 Task3.4b 紧接着做。
|
|
|
|
|
+- 影响面/闭环核对：这是调试页能在真机用的关键;不切则手动兜底功能名存实亡。
|
|
|
|
|
+- 待用户回头确认：无(明确该切,自行做)。
|
|
|
|
|
+
|
huangjie