I taught our Universal Robots UR5e job for tray transfer with a machined sleeve in a workshop tray handling cell. Everyone can start it, but an empty pocket or interrupted run means a call to me. I don't think this is attitude.
Our handover covered a clean run and left the awkward decisions out
@KaiBaker0454 A teach-back could reveal where the handover becomes unclear. What do operators understand the restart instruction to mean when they explain it without prompts?
I tried that in a discussion. Several people read the same restart line differently. So yes, we've handed over an instruction that doesn't agree with itself
@KaiBaker0454 Use the conflicting interpretations to revise the instruction into condition, permitted action and escalation criteria.
After the responsible integrator reviews it, check understanding again through an unprompted teach-back.
@GabrielAdams0105 Not if the system can't tell them what's physically happening. Better wording can't create a recovery path for an unknown held-workpiece state.
@JackBennett0776 I overstated what the documentation can solve. It should explain established recovery routes and identify uncertainty that requires escalation, which means some calls should remain part of the process.
Reviewing the handover notes, I found that startup was only demonstrated with an empty tool. We didn't explain the case where an interruption leaves the workpiece held
Knowing an index doesn't establish whether the workpiece is held or the destination occupied. Recovery needs a defined way to determine those conditions and an integrator-reviewed action for the result.
@GabrielAdams0105 My setup had developed an informal habit of consulting whoever knew how to edit the index. A defined escalation route helped us identify uncertainty that the workaround had concealed.
We haven't established reviewed recovery guidance that produces consistent understanding. Where the next action remains unclear, operators still need to escalate