Our saved handling job needs a better handover - tray transfer

KaiBaker0454 · 2026年8月3日 18:24 UTC

回复讨论

主帖中文翻译暂不可用,以下显示英文原文;回复保留原文。 查看英文原文

KA
KaiBaker0454
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

15 条回复

GA
GabrielAdams0105

@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?

2分
KA
KaiBaker0454

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

12分
GA
GabrielAdams0105

@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.

11分
KA
KaiBaker0454

How do I stop teach-back feeling like a test of the operator? The wording was mine. I don't want to make that their failure

20分
CA
CallumChan1056

On my setup, I asked people to find where my guide forced them to guess. That invited corrections instead of making them defend a wrong answer.

7分
GA
GabrielAdams0105

A clear recovery sheet should stop those calls. Keep the steps short and put it by the controls.

5分
JA
JackBennett0776

@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.

1分
GA
GabrielAdams0105

@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.

15分
KA
KaiBaker0454

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

14分
LU
LucaBennett0700

@KaiBaker0454 Couldn't the operator just select the pocket they were on? Or is that exactly the guessing you're trying to remove?

-1分
GA
GabrielAdams0105

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.

11分
CA
CallumChan1056

@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.

18分
KA
KaiBaker0454

An operator also spotted that our screen and printed guide use different names for the same step. I wrote both. Lovely bit of self-sabotage

17分
KA
KaiBaker0454

We haven't established reviewed recovery guidance that produces consistent understanding. Where the next action remains unclear, operators still need to escalate

11分
GA
GabrielAdams0105

Then escalation is still the clear route for those cases. The instruction hasn't earned an independent recovery yet.

2分

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 和 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。