ZaraArcher0395 · 26 Sept 2025, 00:44 UTC
Save the transfer's stage, not just the next pocket. A pocket number cannot tell you whether its block is still in the tray, held, or placed. Start by naming those states on paper.
20 pointsSo the saved pocket should stay the source until placement is confirmed?
11 pointsWhat if somebody removes the held block during recovery?
12 pointsKeeping the source helps, Zara, but it doesn't settle Jonas's question. The physical state may change during an interruption. Recovery needs a way to confirm what is actually present before continuing.
23 pointsWho is allowed to make that confirmation on your setup? I wouldn't want a screen that asks an operator to accept a part location they can't see.
14 pointsWe had a teaching exercise with a very tidy recovery chart. Everyone followed it correctly until a student handed the held sample to the tutor and then another student took over the screen. The chart still said held. Neither student was being particularly careless; they just had different pieces of the story. That changed the lesson for us. We practised the handover and the unclear case, not only the nice stop where everything stayed put. A remembered program step is useful evidence, but it cannot replace finding out where the sample went.
3 pointsDoes your proposed recovery have an explicit option for an unknown location, Zara? That would let the operator stop the decision instead of choosing the nearest-looking answer.
5 pointsNoah's example is why I'd keep the last commanded stage separate from the confirmed recovery state. Otherwise the operator is asked to agree with the software's guess.
9 pointsNo unknown option yet. Oliver, the person at the screen can see the tray but not the fixture pocket.
16 pointsThen a placement confirmation from that position isn't much of a confirmation. Could your recovery arrangement let an authorised person check the fixture before deciding what happens next?
0 pointsDoes 'placed' mean released, or seated correctly? Those aren't always the same.
15 pointsCorrect. I used placed too loosely. Define the actual completion evidence your application requires, including the receiving fixture, rather than treating a release command as a successful transfer.
21 pointsFor the paper exercise, walk through a stop before pickup, while holding, after release and before saving completion. Give each an uncertain version too. You'll find gaps without touching the real tray.
22 pointsThanks, Rachel. Splitting commanded from confirmed makes the problem clearer. I'll try Elliot's paper exercise with our operator.
14 pointsElliot, would you include the application restarting during recovery? A student may assume an unfinished confirmation survives because the screen returns to the same page.
14 pointsYes. Include losing that confirmation before it is saved, and reopening one that was already saved. The page looking familiar should not authorise another transfer.
14 pointsAnd let the operator say the chart is confusing. We got more useful criticism from that than from asking whether each box was technically correct.
2 pointsPaper exercise found two meanings of complete: released at the tool, accepted at the fixture. We've renamed both.
12 pointsGood catch. Which one advances the tray now?
20 pointsAccepted at the fixture in the proposed chart. Unknown location stops recovery. Software change and testing still ahead.
5 pointsThis discussion is closed to new replies after six months without activity. Last activity: .