Fairino FR10: Keeping failed checks in history without counting every retry

AdaBennett0738 · 22 Jul 2026, 08:39 UTC

Reply to discussion
AD
AdaBennett0738
I'm reconciling our batch of 191 for fixture-based dimensional inspection with Fairino FR10 in a workshop batch inspection cell, using a molded housing. The dashboard looks nearly finished because its post-restart counter includes repeat inspections. Items can have failed checks followed by reviewed retries. I want the accepted-item count to be accurate without discarding that attempt history.

18 replies

AN
AnilBrooks0810
Replying to AdaBennett0738

Pick a traceable item and compare all of its inspection attempts with its current accepted disposition. Does your counter count the attempts rather than the item?

16 points
AD
AdaBennett0738
Replying to AnilBrooks0810

I've traced one item in our saved history and found several successful attempts with the same identity. Our counter adds each success, inflating the apparent batch progress.

19 points
AN
AnilBrooks0810
Replying to AdaBennett0738

Derive the batch view offline from item-level dispositions while retaining every inspection attempt. Counting each accepted identity once should produce the correct total.

9 points
NO
NoraAbbott0061
Replying to AnilBrooks0810

Only if accepted means the current disposition. An item that passed and was later rejected can't stay counted just because it passed once.

6 points
AN
AnilBrooks0810
Replying to NoraAbbott0061

@NoraAbbott0061 You're right about that missing qualification. Use each item's current authorized disposition for the batch total, retaining earlier results without treating any historic success as permanent acceptance.

15 points
AD
AdaBennett0738
Replying to AnilBrooks0810

For an item that fails and then gains reviewed acceptance, should the report count one accepted item while preserving both inspection attempts beneath it?

16 points
AN
AnilBrooks0810
Replying to AdaBennett0738

That's the distinction: the attempt history explains what happened to the item, while its current disposition determines its contribution to the accepted-item total.

9 points
RE
ReeceCarter0993
Replying to AnilBrooks0810

@AnilBrooks0810 On my report, we put attempts and accepted items beside each other. People stopped expecting the numbers to match once the repeated inspections were visible.

8 points
BE
BenAllen0283
Replying to ReeceCarter0993

Does a retry get a new item ID then? Or just a new attempt ID?

15 points
AN
AnilBrooks0810
Replying to BenAllen0283

@BenAllen0283 Preserve the identity of the physical item and assign a distinct identity to each inspection attempt, keeping the relationship between them explicit.

22 points
AD
AdaBennett0738
Replying to AnilBrooks0810

@AnilBrooks0810 The newer entries distinguish item and attempt identity, but some older results lack the item link needed to include them reliably in an accepted-item total.

8 points
NO
NoraAbbott0061
Replying to AdaBennett0738

@AdaBennett0738 Don't manufacture identities from event order to make them fit. Similar-looking results could be retries of the same item.

18 points
AD
AdaBennett0738
Replying to NoraAbbott0061

I'll keep the unlinked results explicitly unresolved pending comparison with our physical traceability records, instead of inventing item identities to complete the total.

4 points
BE
BenAllen0283
Replying to AdaBennett0738

Do unresolved items count as rejected? Otherwise the report's got another number people have to understand.

14 points
AN
AnilBrooks0810
Replying to BenAllen0283

An unresolved item link or disposition doesn't establish a rejected result. Represent that uncertainty separately from both confirmed acceptance and confirmed rejection.

11 points
RE
ReeceCarter0993
Replying to AnilBrooks0810

@AnilBrooks0810 On my setup, a manual quantity adjustment had explanatory text but no traceable item evidence. We had to distinguish the adjustment from an actual additional accepted item.

2 points
AD
AdaBennett0738
Replying to ReeceCarter0993

@ReeceCarter0993 Our accepted quantity remains unresolved. The counting error is understood, but the full item-level reconciliation isn't established.

4 points
AN
AnilBrooks0810
Replying to AdaBennett0738

That status matches the remaining item-level gap, even though the source of inflated progress is clearer.

10 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.