I maintain an FR10 teaching bench with a PLC job interface. We unplugged the monitoring laptop after a sample check had completed. Reconnecting added another completed row to the lesson record, although nobody submitted another job.
The PLC completion state stayed high throughout. Our monitor treats the first high value it reads as an event. I need a recovery rule that an instructor can explain and support without clearing evidence or submitting the check again.
We got caught by that with a test logger. A counter was unique until the equipment restarted. What did your PLC do during this particular outage: remain running, or restart as well?
Only the laptop disconnected in this test. The PLC kept running. Its counter can be reset during maintenance, though, so it is not a permanent unique identifier by itself.
Please include the operator view. Two rows corrected in the database can still leave an instructor with a misleading total on screen. One explanation for both (and somebody responsible for making the correction).
I have added a proposed controller-run identity to the interface review. For the existing data, only the observed reconnect pair is being reconciled. Unknown matches will be flagged for review instead of discarded.
Also try losing the connection after the row is saved but before the monitor records that it handled it. That's where our logger duplicated things even with a good job identifier.
That reproduces the problem too. We are changing persistence so recognising an already recorded result does not depend on the monitor reaching a later in-memory step. No new work is submitted during recovery.
The laptop reconnect cases now display one completion in our offline tests. Maintenance reset handling still needs the PLC owner's review, so I am keeping the issue open on the handover sheet.