HazelArcher0397 · 30 May 2025, 23:52 UTC
Use the retained job reference with the saved result, if both have it; can you see the same identity on the duplicate pair?
17 pointsYes, same job number in both saved rows. The monitor forgot its previous bit state and treated the first reading as a new completion. That's what the developer found, anyway.
19 pointsAsk them to reproduce it from the captured data and check a result completed during the outage too, because that second case still needs recording once
24 pointsDoes that job number ever restart?
-1 pointsYes, after maintenance resets. So matching the number alone has a catch. I've asked controls what identifies the run it belongs to.
24 pointsThere is a run value in the retained registers. The monitor doesn't save it with the result. Developer is adding that to the proposed fix.
3 pointsAnd the old rows without it will need care; I'd leave any uncertain matches for review rather than have the new code quietly decide they are duplicates
15 pointsShow that review state clearly and name who handles it. Recovery of the display should not issue new robot work or erase the retained job information.
7 pointsCould you first reconcile the one pair you actually watched duplicate? It gives the reviewer a concrete example before they tackle the older rows with missing run information.
8 pointsYes, keep the change traceable; our totals get copied elsewhere, so correcting the source number without saying why can leave two different totals circulating
7 pointsThe watched duplicate is reconciled with quality. Offline tests now use run and job together and handle the two outage cases once each. Older uncertain rows remain flagged. Nobody cleared the PLC bit to make the screen look tidy.
7 pointsDoes the operator see which total still needs review, or is that only visible to the developer?
23 pointsThis discussion is closed to new replies after six months without activity. Last activity: .