Connector loading waits at an empty destination

Harish, possible, but don't turn the loader into the suspect before Rosa knows which condition is missing. A half-written changeover sequence can leave them doing exactly what the instruction says.

Lin: job says occupied, although that pocket is physically empty. Harish: the instruction includes exchange confirmation, and the loader followed it. Support has now named the retained destination-status field they want with the job identity.

Then compare which destination that exchange confirmation cleared. It might be correctly recorded against a different tray job. I would not ask the operator to repeat it blindly while the ownership is unclear.

Rebecca, agreed. Rosa's answer makes the distinction important. I was describing our case, not accusing her loader of skipping something.

Nina, destination names were abbreviated and too similar. The retained trace also shows exchange clearing the previous tray job, while the active job keeps its occupied state. Programmer is checking that mismatch.

That sounds painfully familiar in the wording, although the job-state mismatch is your own finding. Keep both in the correction: clearer names won't fix which job receives the confirmation.

Will the revised screen let the loader see the active job before confirming the exchange, Rosa? I'd want that answer from someone using it, not just someone who wrote it.

Revision ties exchange confirmation to the active destination identity and rejects the old job's confirmation. Offline tests cover both cases. The clearer names passed a walkthrough with our loader, who spotted the mismatched example unaided.

Has that correction reached the installed station, or is it still the tested revision waiting to go in?

Installed and checked with the integrator. Two normal tray exchanges completed, and the mismatched-job test held for review instead of clearing another destination. This ticket is closed. Thanks for asking about the condition behind the message, Farah.