How should our FR10 verify cover-insert identity after a changeover?

Anil, latch only. LiamCarter, the mark is underneath. Both family and reversal need addressing.

Do not infer family from that latch signal. The interface should distinguish an identified matching insert, a mismatch and an unreadable or absent identity. A cached last-good value must not stand in for the new insert.

Have the designer consider preventing reversal physically. Software should not be asked to rescue every avoidable wrong fit. That still leaves family and recipe agreement to solve.

Anna, agreed, provided the proposed keying is checked with both families. A single successful correct-fit demonstration is an admirably selective way to miss the other combinations.

The spare inserts belong in that review too. If the approved prototype has a new mark or locating detail, stores needs to know which earlier replacements are no longer suitable. Otherwise the next changeover can undo the design work.

I would let an operator try the proposed identification message on paper first. The detected family and selected recipe may be clear to the programmer and still confusing on shift.

Adam, include unreadable too. Different help needed from definitely the wrong family.

Designer is comparing keying for both families. Controls has the separate mismatch and unreadable cases. No method chosen.

Who will own the approved insert list and its replacement revisions? Stores can hold the right spares only if tooling and controls issue the same list. A handwritten recipe name on an old insert is not a reliable update process.

Alex, try the existing wrong combinations on the drawing before buying a reader. You may learn which mistakes geometry can remove and which still require identification. I'm not suggesting a label alone is enough for the remaining check.

Isabel, yes, but that review should include the wrong recipe with the correct insert too; changing the carrier geometry will not remove that combination.

Victor, can stores distinguish the old and new revisions without unpacking and measuring every insert? I'm asking about the eventual supply, not claiming Alex has new ones already.

That should be part of the replacement specification. Readable identity on the actual insert as well as its packaging, with an agreed disposition for superseded stock. I would not invent the markings before tooling defines the revision scheme.

Jasper, tooling owns the list with controls approval. Operator review is arranged. Keying proposal still on paper.

Include removing an insert after a successful check, then restarting the application. The old valid state must not become permission to use whatever is fitted next.

Priya, thanks for the unreadable example. I'll include that when we ask the operator what they would do, without first telling them which answer we want.

Alex, will the offline tests assert rejection as well as successful use? A system that refuses everything could otherwise look wonderfully cautious and be completely unusable.