Our UR5e coupon-check dashboard counted a saved result again after reconnect. Its local event detector forgets the previous bit state. I'd like a reconnect test that checks the bookkeeping without clearing PLC evidence or resending jobs
We reproduced that offline by replaying a retained completion into a freshly started monitor. Use the recorded job identity as well as the bit, and compare what was already saved before disconnection. A fresh monitor should not imply fresh work.
Add a case where the monitor disconnects before the result is saved. You need that result recorded once after reconnect. Otherwise a fix that suppresses all startup completions can pass your first example and lose genuine work.
Yes, establish that before treating the number as permanently unique. Our offline records included a run identifier because the local counter restarted. Yours needs a documented identity rule, not necessarily the same implementation.
We have a retained run identifier already, but the monitor drops it when saving results. I'll have that omission reviewed. Existing rows can't all be matched confidently after a counter reset.
Keep those older ambiguous rows distinct from the known reconnect duplicate. You can correct the confirmed duplicate with an audit trail without claiming to have reconstructed every historical result.
The instructor display also needs a defined state for unresolved history. A total with an unspoken caveat is likely to be copied into records. Decide who can reconcile it and what evidence they must review.
That is worth capturing in the reproduction steps. A reconnect event and a manual refresh might share code, but they are different triggers and should not be assumed equivalent.
Immediately on connection, no button pressed. Manual refresh didn't add a row in the captured test. I've recorded the trigger and retained the old results file for comparison.
That case duplicates too in the old monitor. The revised offline version keys the saved result by run and job, and both reconnect cases now record it once. Historical uncertainty is still a separate review item.
Useful progress. The live acceptance check still needs the agreed interface and display behaviour verified with the controls owner; the offline replay establishes the application response to those supplied records.