FR10 saved pocket ahead of the block

Olivia_Blair · 13 Dec 2025, 06:21 UTC

Closed
OL
Olivia_Blair
Our FR10 saves the next pocket before placement finishes. After interruption it can skip a block. Clean runs hid it.

18 replies

TH
TheoBrown0932
Replying to Olivia_Blair

Define the interrupted stages before moving the save instruction. The design must distinguish a block still at source, held by the tool, placed, and not yet confirmed. One pocket number cannot describe all of those.

9 points
OL
Olivia_Blair
Replying to TheoBrown0932

Controls suggested saving after release instead. That leaves the opposite gap, doesn't it?

11 points
CH
ChloeBell0657
Replying to Olivia_Blair

Yes. A stop after release but before the save can leave the stored position behind. The recovery design needs to handle uncertainty, not just move it to another line

20 points
YA
YasminBaker0441
Replying to Olivia_Blair

Does startup show the saved number as a confirmed empty pocket?

17 points
OL
Olivia_Blair
Replying to YasminBaker0441

It says next pocket. No uncertainty shown.

9 points
PA
PavelAdams0092
Replying to Olivia_Blair

Who is expected to reconcile the interrupted transfer when the operator cannot establish where the block is, Olivia? That responsibility belongs in the design as well as the stored states.

2 points
TH
TheoBrown0932
Replying to Olivia_Blair

Yasmin's wording point matters. I would have controls hold an uncertain transfer for the agreed reconciliation, with the last stored information identified as such. Reopening must not convert it into a fresh request.

20 points
CH
ChloeBell0657
Replying to TheoBrown0932

And reconciliation is more than choosing a screen value. The physical recovery and access need assessment with the integrator before those choices become operator instructions

9 points
OL
Olivia_Blair
Replying to PavelAdams0092

Designated maintenance lead, Pavel. Agreed method still outstanding. We're not handing this to production yet.

21 points
YA
YasminBaker0441
Replying to TheoBrown0932

Can the software test a stop at both sides of release without moving hardware?

17 points
TH
TheoBrown0932
Replying to YasminBaker0441

The developer can test the state logic with simulated observations and interruptions. That is useful coverage, but it will not establish how the real placement is confirmed or how physical recovery is carried out.

6 points
OL
Olivia_Blair
Replying to TheoBrown0932

Offline cases now include both gaps. Also reopening with the block state unknown.

9 points
CH
ChloeBell0657
Replying to Olivia_Blair

Cases written, or passed?

22 points
PA
PavelAdams0092
Replying to Olivia_Blair

Olivia, include a repeated interruption during reconciliation in the discussion with the maintenance lead; people can be called away before an agreed recovery has finished.

25 points
OL
Olivia_Blair
Replying to ChloeBell0657

Written when I posted. Passed now, with unknown remaining held after reopening. Physical method still under review.

15 points
TH
TheoBrown0932
Replying to Olivia_Blair

Does the test also reopen after the second interruption Pavel describes? A hold that survives one restart may still be cleared accidentally by a later path.

4 points
CH
ChloeBell0657
Replying to Olivia_Blair

Keep the operator trial separate from those software results. Someone unfamiliar with the fault should understand why the station is held, without being invited to guess the missing placement

7 points
YA
YasminBaker0441
Replying to Olivia_Blair

What will it display if the tray identity is missing too?

13 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .