Our FR10 inspection total rose when the monitor reconnected. Same bracket in the fixture, retained completion still high. The proposed patch ignores the first reading after reconnect.
That might hide this duplicate. It also sounds capable of hiding a result completed during the outage. I need a recovery explanation I can hand to operators.
The reconnect counted a bracket nobody touched
NadiaChan1074 · 2025年3月21日 11:44 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
6 条回复
AL
What identifies the completed job in the retained registers? You need to compare known results, not throw away a reading because it arrived first.
11分回复 AlexCell
There is a retained job identifier. The local results file also stores it. The monitor's counter ignores that file on startup and just counts observed completion changes.
4分AL
Reconcile the retained identifier with saved results on reconnect. How does the interface prevent identifier reuse from making a later job look like an old one?
24分Include both outage cases in your offline tests: a result already saved, and a result produced while the monitor was absent. Ignoring the first reading makes one screen look right by losing evidence from the other.
4分AL
回复 AlexCell
Did you establish the identifier lifetime? That's still needed before matching against the saved file can be treated as reliable.
25分回复 AlexCell
Identifier reuse is possible after controller maintenance. Controls is revising the interface to include a run boundary. The blanket ignore-first-reading patch is dropped; uncertain matches will stay visibly unresolved during commissioning.
17分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .