the dashboard counts retries as extra plates

JuliaBrooks0848 · 24 Aug 2025, 10:10 UTC

Closed
JU
JuliaBrooks0848
Our UR5e inspection lesson says the batch is nearly finished. Except the counter is counting passed attempts, including repeats on plates already accepted. We need unique accepted plates. Also need the failed attempts, because some plates had a reviewed retry and that history matters. I don't want to fix the cheerful number by deleting the awkward rows. Anyone got a clear way to explain this to the person changing the report?

15 replies

VI
VictorBell0620
Replying to JuliaBrooks0848

Show them one plate with several attempts and ask for one current item decision alongside the whole attempt history; adding another attempt should not create another physical plate in the batch.

5 points
JU
JuliaBrooks0848
Replying to VictorBell0620

Made a tiny example. One failure, approved retry, pass, then the same pass delivered again after restart. Their query counts two passes. At least we can reproduce it without the robot now.

6 points
VI
VictorBell0620
Replying to JuliaBrooks0848

Give that replay the same attempt identity as its original result, or the example will accidentally describe a new inspection rather than a duplicate delivery.

12 points
BE
BenBrown0892
Replying to JuliaBrooks0848

Does a later failed check ever withdraw a plate's earlier acceptance? You need that rule too. Counting anything that has ever passed sounds simple until someone reviews an accepted plate again.

7 points
PR
PriyaBennett0742
Replying to BenBrown0892

Have quality define the current item disposition, including a reopened review, before making the report infer it from whichever result has the latest timestamp.

6 points
JU
JuliaBrooks0848
Replying to PriyaBennett0742

Quality says reopened review removes it from accepted until a new disposition is authorised. Programmer now has separate item, attempt and received-message examples. The original failed check stays visible.

5 points
VI
VictorBell0620
Replying to JuliaBrooks0848

And keep that authorised disposition linked to its supporting attempt and review, so a trainer can explain why the plate counts without pretending its earlier failure disappeared.

17 points
BE
BenBrown0892
Replying to JuliaBrooks0848

What about plates with no readable label? There always seems to be one that somebody wants included because everyone knows which it is.

18 points
LI
LinBrooks0792
Replying to BenBrown0892

We had exactly that argument over a smudged label. The report wasn't the place to resolve it. Put unmatched work somewhere visible for review, otherwise the nice total becomes an invitation to guess.

9 points
JU
JuliaBrooks0848
Replying to LinBrooks0792

Unmatched records now stay outside the accepted item total with a review count beside it. No automatic match by time. Added a same-label-in-another-batch example as well, which exposed another shortcut.

6 points
PR
PriyaBennett0742
Replying to JuliaBrooks0848

Does the item identity include the batch context where labels can be reused?

14 points
BE
BenBrown0892
Replying to JuliaBrooks0848

And has replaying the full saved history produced the same total as receiving those messages one at a time? I'd like to hear that result.

11 points
JU
JuliaBrooks0848
Replying to BenBrown0892

Priya, yes, labels are scoped to the batch. Ben, full replay and incremental processing now agree across our saved cases, duplicates included. Quality checked the resulting item list against the batch records. Revised report accepted.

2 points
JU
JuliaBrooks0848
Replying to VictorBell0620

Thanks, Victor. One plate with a messy history explained this much better than my original paragraph about counters.

20 points
LI
LinBrooks0792
Replying to JuliaBrooks0848

Keep that messy plate in the lesson. The spotless example teaches everyone the one case that never needed explaining.

17 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .