|
|
@@ -140,3 +140,19 @@
|
|
|
- 根因定位:① 配置排除——查 house_well_setting/tl_setting,4号舱对焦范围/层/阈值配置与好舱完全一致(范围列全空→四舱同吃引擎默认 ±6000/±2000;峰比阈值设备级 1.2 共用);② 故为 **4号舱物理/样本问题**:最可能孔内无可成像目标(废弃鼠胚未放进孔/皿没卡到位),或光路起雾/脏污,或皿工作距离异常焦面落范围外。软件行为正确(检出对焦失败→不用坏位置→安全保留旧位置)。
|
|
|
- 关联:4号舱粗对焦落在 72000~80000 偏低区(真实焦面应 ~86000-92000),与"74000伪峰"症状(代码注释:偶发粗对焦被~74000假峰骗、峰比≈1.0)形态相近;但74000伪峰是"偶发单孔",4号是"全16孔系统性低",更像真无目标。两者需现场连同看一眼。
|
|
|
- 待办(现场):看一眼 4号舱那个皿——胚胎是否在孔里、皿是否卡到位、观察窗有无雾。不影响 2/6/8 正常出图与崩溃修复结论。
|
|
|
+
|
|
|
+#### [Phase5·#7] 端到端打通:启用安全门=1 + 修两处服务器侧上传链堵点 — 2026-06-26
|
|
|
+- 背景:local_autofocus_enabled 设备级已=1(本地对焦正式启用)。验"端到端"时发现:本地拍照存图正常(全分辨率2592×1944),但**服务器图片表今晚0记录、FastDFS无新文件** → 上传到服务器这一段断了。逐段排查定位两处堵点(均为测试环境/服务侧,非D2-02代码):
|
|
|
+- **堵点1:Kafka 单条消息上限太小**。control 经 Kafka topic `CCD-PICTURE-NEO-1-20230411` 传整张图(ByteString),control日志报 `kafkaProducerAsync异常: Message size too large`。查 108 Kafka 无 message.max.bytes 配置=默认1MB,而修复后图片~1.1MB(2592×1944全分辨率)→被broker顶回。**修:动态设两个图片topic max.message.bytes + broker默认 message.max.bytes = 5MB(免重启)**。(正式环境本应已放大以传2592×1944图;测试服108漏配。)
|
|
|
+- **堵点2:data-transmission 服务昨日遗留半死**。改完Kafka后图能进topic(三分区共~2017条),但**消费组无图片组、服务不监听10030端口**。查其日志停在昨天14:35、末尾为 Feign/Ribbon 负载均衡调用失败栈——它启动时 addTl 流程(遍历TL→startPictureReceiveTopic 开图片消费)的Feign调用失败,致图片消费者从未启动。**修:照 start-all.sh 命令重启 data-transmission(需 lib 原生DLL JavaImageDLL/opencv_world3416 在PATH + jna.library.path,-Xmx256m)**。
|
|
|
+- **验证(端到端全链路打通)**:重启后 data-transmission 10030监听、日志 `ReceivePictureMessageInfo#receive` 收图入库;消费组 `wyl02` 出现;**服务器 picture_neo_1_20230411_<舱> 今晚入库 house2=203/4=294/6=408/8=205(共1110+),FastDFS 新增4510文件**。链路:本地四步对焦→FocusZ上报→服务器排对称层→取层→拍照→存图(2592×1944)→Kafka→data-transmission→MySQL+FastDFS,**全通**。
|
|
|
+- 影响面:两处修复均为测试环境服务侧配置/运维(Kafka上限、服务重启),无代码改动。控制侧端到端早已验证(对焦闭环+多舱崩溃根治)。
|
|
|
+- 待用户回头确认:① Kafka message.max.bytes 在正式部署环境是否已放大(测试服我设了5MB,正式环境需核对);② data-transmission 昨日 addTl 启动期Feign失败的根因(依赖服务启动顺序/Nacos注册时序)——本次靠重启绕过,正式环境建议查启动编排;③ 图片消费组名 `wyl02` 似为开发期遗留命名,留观察。
|
|
|
+
|
|
|
+#### [Phase5·#6] 三门验证 + 电机安全:真机数据取证结果 — 2026-06-26
|
|
|
+- 在4舱(2/4/6/8)同时对焦+拍照的真机run上,从日志/代码取证四项:
|
|
|
+- **门1 74000伪峰**:好舱粗对焦Z分布 house2~84000、house6/8~74000-76000;但 8号舱在~74000拍出的是清晰胚胎图(肉眼可见核仁纹理)→ 74000是house6/8的**真实焦面**(各舱皿高不同),非伪峰;3好舱16孔全出清晰图=未被伪峰骗。**本run未复现伪峰**(该bug偶发,长跑续观察;motor-settle修复在代码内)。✓(本run)
|
|
|
+- **门2 峰比阈值1.2**:真胚胎舱合格率 house2=90/96、house6=92/96、house8=71/96(部分空孔);空孔的 **house4=0/96 全拒**。1.2阈值把"真焦点(峰比1.3~1.8)"与"空孔/失败(≈1.0)"干净分离。✓
|
|
|
+- **门3 EEPROM(对焦不写)**:对焦源码(IvfTl.AutoFocus + HouseBin)**无任何写EEPROM调用**(grep仅匹配编译dll),运行期亦无写EEPROM日志 → 对焦只在内存算FocusZ+上报、**不回写EEPROM基准**。✓ 注:"4个手写值生效"(读取生效)部分,对焦确以EEPROM的 eepromHPos/eepromZ 为输入(CalibrateWell入参),但"手写4值并确认生效"需调试页实操写入核对,本次未做。
|
|
|
+- **门4 电机安全区间**:数小时4舱对焦全程**无钳位/越界/撞机告警**;对焦Z(~74000-84000)、水平位(~71000-206650)均在限内(ZMax=125000/HMax=220000)。✓(本run)
|
|
|
+- 结论:门2/门4 本run充分验证;门1本run未复现伪峰(续观察);门3"对焦不写"已验、"4手写生效"待调试页实操。安全门已=1运行,与三门结果不冲突。
|