Our FR10 sensor-cover insert resembles another family insert and appears able to fit backwards; before automated use, I need an installed-tooling check that corresponds to the recipe, not merely a label beside an unchecked selection.
Lay the candidate inserts and their approved drawings together with the tooling owner first. Establish identity, orientation and correct seating as separate questions. A label can help a person recognise the insert, but it cannot by itself stop the wrong insert fitting or prove the installed state to controls.
Then reversed fit is still a possibility, not a demonstrated condition. Ask the toolmaker to check it with the identified parts before choosing the remedy.
What information does controls receive about the installed insert now? Recipe selection and a human-readable label may describe intention without establishing what was actually fitted, so I would map the present information before adding another confirmation screen.
I'd involve the people changing inserts at that first comparison. They may know when a label is covered by a clamp or turned away from the normal working position. That doesn't replace an engineered check, but it saves designing an identification step that requires somebody to lean around the fixture every time.
Controls receives only the selected recipe. There is no installed-insert identity or seating information. The operator's confirmation is the only link in the current proposal.
Then the proposal needs a design decision, not stronger wording on the same confirmation. The tooling and controls owners should consider preventing the wrong family or orientation mechanically, and defining what check establishes the installed assembly and valid recipe relationship. I am not prescribing a particular sensor from this description.
David, a mechanical key could address orientation without identifying the family. Or the reverse. I would ask which mismatch each proposed measure actually prevents.
Yes, and seating may still be separate. A readable identity is not proof the insert is fully home. The agreed design needs to state what conditions permit the ordinary job sequence and what happens when those conditions are absent or inconsistent.
Zara, include what the operator sees in that inconsistent state. I would want the display to identify the problem it actually knows, not accuse someone of fitting the wrong insert when the system merely failed to read it.
The toolmaker confirmed that the sensor-cover insert can seat reversed in the current carrier. Tooling and controls are comparing prevention and identification options; no revised carrier or sensing method has been selected.
Will the design invalidate the previous check when the insert changes? That requires a defined means of establishing change or a controlled changeover process; the old verified flag must not simply survive every subsequent installation by default.
That is now a review question. The current recipe confirmation persists until another recipe is selected, so removal and refitting do not create a new check.
That is a concrete gap worth reproducing in the planned interface test. Correct insert, removal, different insert, same selected recipe: the expected outcome should come from the agreed design, with the job prevented from proceeding on stale confirmation. A test sequence alone does not supply the missing detection or process control.
Who will own the accepted insert references in stores once the design changes? I have seen a sensible changeover scheme become confusing because the replacement insert arrived with only a family nickname on its bag.
Our tooling coordinator will own those references with stores. Reversed seating and stale confirmation are documented in the review; both remedies remain undecided, and automated use has not been authorised.
Please retain both demonstrated gaps when reviewing the final proposal. Solving reversed seating would not by itself answer the stale recipe confirmation, and a new confirmation screen would not necessarily solve reversed seating.