Our FR10 bench accepted a sample bracket once. Then the reporting application lost its connection and came back with a second accepted tick. Same bracket still in the fixture, no new inspection. Very productive software.
I've got the saved messages from that interruption. The completion was high on both sides of the gap. Can we make the reporting sensible without clearing the PLC state just to get a clean-looking screen?
Yes, but first find out whether the second tick is only on the screen or has become another stored result. I'd start with the saved entries for that bracket, not change the PLC.
What does an operator do with an accepted tick on this bench? If it releases paperwork or tells them to unload, the display wording matters as much as the total.
It's the inspection report screen. Unloading is separate. Two saved rows have the same job reference and result, but different arrival times. The report adds both.
Liam, that sounds right if the job reference is unique for every inspection attempt. Rebecca, can the same bracket be inspected again with the same reference? That is where a simple duplicate filter can lose a real result.
Noah, the reference is our worksheet number and gets reused for a recheck. Henry, the failed row stays, then the recheck adds another row. So counting each worksheet once would throw useful stuff away.
I'd keep the failed inspection and the recheck separate on the screen too. Someone reviewing a bracket needs to see why there are two results, not guess which row is the accidental repeat.
You need an attempt identity that survives the connection dropping. New inspection attempt, new identity. Repeated delivery of the same attempt, same result entry. The worksheet can remain the link between them.
Beside it on an inspection report, Henry. Perhaps collapsed details, but not a hidden failure. On a small operator screen I might do it differently because they have another immediate job to do.
Our developer has made an offline version with separate attempt IDs. Replaying my interruption adds one result. A deliberate recheck adds another and both stay linked to the worksheet. This is much closer to what I thought we already had.
Who assigns the attempt ID in that version? If the reporting application creates a fresh one when it sees completion after reconnect, you'll get the same fault with a nicer column name.
The inspection job creates it before starting, and the captured completion carries it. The reporting side doesn't invent it. We haven't tested a restart of the job side yet.
Yes, Liam. Failed first attempt, accepted recheck, two rows. Sofia's suggestion helped: the worksheet heading groups them without pretending the failure never happened.
Henry's question is worth doing before spending ages tidying it. I've watched people read only the big green heading and miss the earlier failure underneath. The grouping needs clear result labels, not just colour.
The restart case is still the one I'd put next in testing. Include a result saved just before the reporting side stops, then delivered again afterwards. That's a very ordinary way to get the duplicate back.