I can recover our proposed FR10 sleeve-transfer sequence perfectly, provided nobody does anything inconvenient like change the tray. In the simulation, stopping after a placement but before advancing the saved pocket can send the next sleeve to an occupied pocket. If the tray was replaced, that same pocket may be empty instead.
This is still a design exercise. I want to give the bench operator a recovery choice they can actually make, rather than ask them to remember what the software forgot. How are people handling tray identity as well as transfer state?
I'd make a tray change a separate event the job has to recognise. Otherwise a recovery screen can show perfectly accurate information about a tray that is sitting somewhere else now.
Start with two paper trays and a few marked sleeves. Swap one during your recovery walkthrough. Cheap way to discover whether the operator can distinguish them using the information you intend to provide.
Also worth asking what happens to the partly filled tray after removal; if it returns later, 'fresh tray fitted' may have become a rather generous description.
I wasn't necessarily proposing a scanner, Aaron. But Bruno's returning tray needs distinguishing somehow, and a person ticking fresh without seeing the pockets won't solve that.
Partly filled trays can return. They go to a nearby checking bench. That's why I don't like a blanket fresh-tray confirmation. We have tray labels already, though my simulated job ignores them.
Use those labels in the paper test first. And have somebody other than you read the recovery screen. You know which tray you meant even when the screen doesn't say it.
Thanks, Isabel. I jumped to extra hardware. Existing labels might be enough for the first walkthrough, with the possibility of reading the wrong one included.
Can the same label stay with a tray after its contents have been emptied and refilled? Tray identity and the current filling job need not be the same thing.
Yes, labels are permanent. So I need to stop treating tray identity as an inventory of its contents too. This is becoming a useful list of things a pocket number cannot tell me.
The checking bench matters here. If somebody removes a sleeve there, how does that change reach the job when the tray comes back? I'd settle that handover before drawing more recovery buttons.
Would keeping interrupted trays out of the automatic queue be acceptable initially? Less convenient, but it might keep the first recovery design small enough to test properly.
Our operator preferred that limited pilot option in the walkthrough. Interrupted trays go to checking and don't re-enter the automatic queue. Checking already owns their disposition. We still need recovery for a sleeve held when the job stops.
That removes the returning-tray case from the pilot, not from the eventual design. I'd keep it visible so somebody doesn't add tray return later as a harmless convenience.
For the held sleeve, don't infer its presence solely from the saved pick step. Your simulation should include the uncertain case as well as the sleeve still sitting neatly in the jaws.
And let checking see which sleeve or tray the operator has referred to them. Saves the support person arriving to a tray and a note saying problem, which is not much of a handover.