Opening the monitor adds a plate we never inspected

PLC has job 28 with a pass. Application saved a pass and time, but no job number. Both rows have different application times.

Those times are observation times. Don't use them as job identities.

Can job 28 be reused after a PLC restart? If it can, adding the number alone would leave you unable to distinguish two genuinely different jobs later.

We hit that maintenance-reset problem on another register. A run boundary went into the interface review. I'd ask about restore from a backup as well as an ordinary restart.

Normal restart retains it. Maintenance can reset the sequence. Controls says the present number is not unique across those resets.

Then keep the reset boundary with the job reference in the proposed design; quality needs a plate's attempts linked together without accidentally joining it to another plate after maintenance.

Different things: job identity and physical plate identity. You'll need both if plates get retested.

Yes, I put those too close together; I mean preserve the link between an attempt and its plate, not use the plate number as the attempt number.

The developer has separated those in the draft. They still want to delete my duplicate row by matching its time to the PLC result. I don't think that match is certain.

Is there any other retained evidence tying both rows to this plate? I would want the correction explained from what you can recover, without treating the proposed new identifiers as though they existed in the old data.

Operator sheet lists one check, but does not have a job reference. It supports one check happening. It doesn't identify which saved row to keep.

Leave that to whoever owns the register correction. Don't silently delete a row and send the next shift a lower total with no explanation.

And preserve the original export before correcting anything.

Quality has the original export and has marked the pair for review. New mock test now delivers one result twice and counts it once, using the proposed run and attempt references.

Does it also count a result first seen after reconnect, rather than always ignoring that first message?

Yes. Unseen completed attempt counts once on reconnect. A repeat of that same result makes no change. Conflicting result for the same attempt is flagged instead of overwritten.

What happens if the application stops after saving the result but before updating its total? That interruption could leave another discrepancy even when duplicate messages are recognised correctly.

We reproduced that gap. Developer is changing how the saved results and displayed count are kept consistent. Glad we tried it before calling the counting fix finished.