FR10 saved pocket ahead of the block

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

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

It says next pocket. No uncertainty shown.

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.

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

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

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

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.

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

Cases written, or passed?

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.

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

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.

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

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