二维码挪盘不中断：成熟做法与410改造方案

用户已明确：当前采用扫码器扫描二维码。本方案固定沿用二维码识别，复用工业扫码器的成熟做法。建议将“读出身份”“物体是否在位”“菜盆减了多少重量”分成三条信号，再由程序管理同一次取餐。夹子可能回盆、也可能不回，不能用夹重判断餐盘是否拿走。

1. 别人已经怎样做

以下聚焦已实际读取的工业扫码器原厂手册。它们证明技术和产品已有先例；未公开的现场失败率、完整业务状态机和本410适配效果不作推测。

因此，已有成熟组件和架构可用。我们还需要完成的是：把板卡实际信号开放出来、修复已经发现的SDK/应用问题、定义这台设备的识别区和取餐规则，再按实际动作验收。通用读码器不会自动替我们的App处理A02/A03、换盘、人员请求和订单归属。

2. 先把我们已有的条件说清楚

用户已确认：扫码器扫描二维码；秤称菜盆；夹菜夹子可能放回盆里，也可能不放。 菜盆重量不直接承载码牌/餐盘的在位信息。

代码核验对象：ZhctWeightingTableYoukate master 2f759f9415b46a7166215fa670d5b4fafeef615e。新发现如下，均为源码事实，未改代码：

核心定位：YoukateHardwareManager.java:125,268,329；HomeActivity.java:466,1963；DarkPickOngoingWithPriceFragment.java:790；DarkPickOngoingNoPriceFragment.java:680。源码相对路径为 app/src/main/java/com/cpt/zhct/weighting/。详见 本机信号与夹重核查。

前轮已复现的解析残帧、异常长度转空、非6位码转空、按回调次数离盘、A02/A03分支差异仍需修复；增加一个传感器不能消除这些代码问题。前轮完整审计

3. 针对识别中断，建议采用的程序结构

下面是基于行业做法和本机证据提出的设计，不是声称别家公开了同一套源码，也不是已在本项目实现。

身份通道：二维码解码内容、读取成功/失败、新鲜度；位置仅在设备实际提供时采用
在位通道：PRESENT / ABSENT / UNKNOWN、覆盖区域、时间和健康状态
称重通道：菜盆载荷、稳定性、夹子状态（若可观测）、时间
                 ↓
取餐会话：等待身份 → 身份确认 → 取餐 → 暂时失读/待确认
                 ↓
同身份恢复继续；明确离开后收尾；换身份单独分流；设备异常单独处理

程序至少需要这些判断：

1. 先分类，后判断离盘。 真正空码、非法码/坏帧、没有新数据、陈旧重复数据、串口失联不能都变成一个空字符串。先修SDK组帧和应用清洗。
2. 普通丢码不立刻结束。 已确认A，码暂时读不到但有效在位信号仍有物体，可保留A会话进入“身份暂失”，等待重获。此时不能把旧码的时间更新成新读取时间。
3. 同身份恢复且连续性校验通过，接续原会话。 不重置起始重量、不重新生成同一笔取餐。若失读期间可能发生A→B→A或重量归属不明，仍保留会话与待确认变化，不能只因再次读到A就把整个空档计给A。
4. 明确离开，才按离开规则收尾。 使用新鲜且有效的在位观测、去抖和明确时间窗；无新数据不能靠超时自动伪装成可靠ABSENT。重量收尾还需稳定与夹重状态满足条件。
5. 不同身份单独处理。 A后出现B，或同区多个ID，进入换盘/身份冲突；不得用B覆盖A，也不得将不明归属的新重量一直记在A名下。
6. 先更新传感状态，再决定发不发查人请求。 修复A02查询进行中跳过有效码清计数的问题；A03核对原盘身份并按各报警子状态分别验收。
7. 单一会话拥有者与请求代次。 读取、切页、查人回包、报警和收尾通过同一状态机串行处理；旧请求不得改新会话。记录幂等键与结束原因。
8. 日志可追溯。 原始帧摘要、质量、在位、ID、计数/时长、配置来源、会话、重量/夹子状态都能按时间关联；故障前后有限环形保存。

在位不等于身份。 手停在识别区、B紧接着替换A时，在位信号可能不断。失读期间无法可靠确认归属、传感器冲突或无法排除换盘时，新增重量暂存待确认，按规则提示重新放盘/扫码；不能无限锁住A继续归账，也不能仅因失读很短就自动放过换盘可能。

4. 挪动时怎么明确“没有拿走”

先把体验分成两层：短时扫不到不误结束可以用在位信号和会话恢复改善；持续知道仍是同一张牌，只在移动则需要在允许移动区持续观测身份，或有经过验证的受控交互约束。

ST多区ToF原厂驱动已有距离、运动量和测量质量分类，可作为区域在位候选；但它不能读取身份，近距串扰和贴近目标的分辨限制必须实测。不能宣传“加ToF便可识别手与牌”。ST UM2884

我的建议：先让厂家开放已有红外的独立状态和扫码新鲜度，验证是否可不加硬件解决短移误结束；若红外覆盖不足或不能回读，再加区域检测。扩大移动范围时，比较二维码扫码头视场/安装角度、二维码多面布局或第二扫码视角；不改变二维码识别介质。 本轮尚未测样机，不预先承诺哪种型号成本最低或准确率最高。

完全离开全部观测区域后再放回，与真的拿走一段时间可能产生完全相同的输入。此时程序只能执行已约定的宽限/重新确认规则，不能凭空判断人的意图。要改善体验，应扩大允许的观测区域、增加视角或明确退出区。

5. 夹子重量到底能不能用

可以参与食物重量补偿，前提是夹子状态可观测；不能决定餐盘/码牌是否在位。 取菜、补菜、夹子回盆和手压菜盆都影响菜盆读数；挪动餐盘却可能完全不改变它。

在盆皮重不变、无补菜、无外力且夹子完全由菜盆承重的简化条件下：

秤体减少量 = 食物取走量 + (开始夹子在盆 − 结束夹子在盆) × 夹重
食物取走量 = 秤体减少量 − (开始夹子在盆 − 结束夹子在盆) × 夹重

下面取菜100g、夹子80g仅为算术演示，不是现场测量：

因此，看到减少180g，既可能取菜180g，也可能取菜100g并拿走80g夹子。即使知道夹重，仍需要开始/结束的夹子状态；每单固定减80g同样会算错。

建议按以下顺序处理：

1. 结构上隔离夹子。 给夹子设置与菜盆秤机械隔离的回位架，使夹子重量不进入菜盆测量。若用户仍把夹子放回菜盆，隔离条件就不成立，必须检测/引导或另走异常规则。
2. 若必须允许任意回盆/不回盆，增加夹子状态观测。 例如受控回位点传感或经过标定的视觉/附加重量通道。回位架“空”只能说明没放在架上，不能区分在手里还是盆里，不能独自完成补偿。
3. 程序使用稳定的边界值与明确状态。 已知两端状态才补偿；夹子带菜、沾液、搭盆边、手触碰等破坏固定重量模型时转待确认，不能把负值截0当作纠错完成。

成熟称重模块同样把稳定性作为“幅度容差+持续时间”的额外状态，并说明振动/冲击及滤波会影响精度与响应时间。这可借鉴到我们的收尾稳定判断，但手册没有替本台提供夹重补偿算法。METTLER TOLEDO SPE手册，PDF第8/24页

6. 用哪些任务把问题真正关闭

验收动作必须包含：静放、区内平移、旋转、靠边、短抬再放、手遮挡后原牌回来、遮挡中换A→B、A走后手仍留、邻台同时放牌、无码取菜、夹子四状态、补菜、串口断流、传感器过期、页面切换及报警。

建议先形成“10种动作×3个区域位置×2种负载/夹子工况×10次”的600次工程摸底，并单列遮挡换盘、邻台和断流等高风险组合；这个规模是本轮试验建议，不是统计意义的最终可靠性证明。正式验收还要固定允许区域、短失读容忍时间、离开延迟、重量误差、工况与样本量。

业务目标：允许区域内挪动不中断同一次取餐；真正离开能够及时收尾；换人不串账；夹子状态不污染食物计量。 不以“提高默认次数”或“所有异常时永远保持旧身份”代替这些目标。

7. 证据与下一阶段契约

本轮完成了公开方案研究和本机信号补查。前轮32项验证属于前轮SDK/应用特征证据，不代表上述新方案已完成样机验证。没有改业务代码、操作设备、采购或联络厂商。

• 来源账本与阅读范围：原厂来源、页码、适用边界和读取失败的处理。
• 本机在位/夹重核查：源码行号、重量误差推导和已有红外接口边界。
• 新增任务Use Case：在原UC上增补移动/换盘与夹重要求；未锁定硬件及关键时限，DoR: BLOCKED。

信心：成熟的分层做法存在、当前菜盆重量不能证明餐盘在位、现有勺重未接入计算，这三项证据较强；具体传感器布局、型号、阈值和现场误差改善幅度仍待同一测试台实测。