I cannot choose the next pocket after an interrupted spacer transfer

MiaCarter0992 · 7 Mar 2026, 17:24 UTC

Reply to discussion
MI
MiaCarter0992
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.

9 replies

JU
JuliaBarnes0587
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.

12 points
MI
MiaCarter0992
Replying 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.

3 points
VI
VictorBell0620
Replying 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?

15 points
MI
MiaCarter0992
Replying 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.

6 points
JU
JuliaBarnes0587
Replying 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.

16 points
VI
VictorBell0620
Replying to JuliaBarnes0587

And reopen while recovery is still unresolved, otherwise the second restart can undo the very caution you added to the first.

21 points
MI
MiaCarter0992
Replying 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.

13 points
JU
JuliaBarnes0587
Replying to MiaCarter0992

Good catch before installation. Have the trainer try the draft with those cases without you explaining what each button secretly means.

13 points
MI
MiaCarter0992
Replying 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.

21 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.