fr5 wait says tray full when it isn't

Pocket advances on placement request, according to our programmer. Confirmation comes later. That sounds wrong to me.

It may explain the empty pockets, but how is an interrupted placement handled? I would want to see one identified attempt through request, any confirmation and the next pocket selection.

I'd also ask what the operator sees during that gap. We had a screen saying ready for the next part while the previous one was still being dealt with, which made the human response look like the fault. It wasn't much fun for the person being told they'd loaded it wrong.

Our display shows the next pocket immediately. The clip catches that, but doesn't show the preceding request.

Aaron, worth checking, but Oscar already has an early increment to explain. I'd send that exact sequence first instead of burying it in five possible causes.

Agreed. Separate question, not my explanation for the empty pockets.

Trace confirms two interrupted requests advanced the pocket without placement confirmation. Same tray identity throughout that run.

That gives the programmer a specific failing example. The revised logic still needs a way to show an uncertain placement, because a missing confirmation does not tell the operator where the connector actually ended up.

Yes. Please don't replace one confident wrong picture with an automatic retry into a possibly occupied pocket.

Revised offline job keeps interrupted placement uncertain. No automatic resend. Tutor resolves it through the agreed recovery route.

Did they repeat those two interrupted requests and a normal confirmed placement against the revision? That's the comparison I'd want in the ticket.

Yes. Interrupted requests no longer advance; confirmed placement advances once. Installed assessment passed those cases too. Ticket closed.