My FR5 sequence picks a spacer, places it, then advances the saved pocket. In the interrupted example, the spacer has already left the tray but the stored pocket still points at it. A different interruption happens after placement but before that advance. Same stored number, different physical situation. I can make an uninterrupted run look fine, but restarting from that number would be guesswork. I want to take a proper recovery design to the integrator, including what the operator has to establish when the saved state cannot tell us whether a spacer is held or placed.
I cannot choose the next pocket after an interrupted spacer transfer
MiaCarter0992 · 7 Mar 2026, 17:24 UTC
9 replies
Replying to MiaCarter0992
Write down those two interrupted cases separately, with the tray identity, attempt and last confirmed action. Then make the uncertain cases stop at a recovery decision rather than reuse the pocket as permission to pick. The integrator needs to agree what physical checks support each decision. You have already found why one counter cannot describe the whole transfer.
12pointsReplying to JuliaBarnes0587
I've made an offline state table. Pick confirmed and placement confirmed are separate entries. If neither tells us the present physical state, the attempt stays unresolved instead of falling back to the normal pickup.
3pointsReplying to MiaCarter0992
Can the operator tell which tray and spacer that decision is about, Mia, rather than being shown confirm and expected to know what they are confirming?
15pointsReplying to VictorBell0620
Not in my first screen. It just said confirm recovery. I've replaced that with the identified tray and interrupted action in the draft, but the actual decision wording needs the integrator and trainer.
6pointsReplying to MiaCarter0992
Include a tray exchange during the interruption. The saved pocket may belong to a tray that is no longer fitted, even if you now remember the last action correctly.
16pointsReplying to JuliaBarnes0587
And reopen while recovery is still unresolved, otherwise the second restart can undo the very caution you added to the first.
21pointsReplying to VictorBell0620
The tray-exchange case stays unresolved in the model. The second restart found a bug: my startup path reset recovery pending to ready. Fixed that and added it to the replay cases. Thanks, Victor.
13pointsReplying to MiaCarter0992
Good catch before installation. Have the trainer try the draft with those cases without you explaining what each button secretly means.
13pointsReplying to JuliaBarnes0587
They did. One phrase sounded like acknowledging a warning rather than making a physical-state decision. We are rewriting that with the integrator. Model fixed, operator wording and station checks still unfinished.
21pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .