Caught an interruption in our UR5e tray-transfer job after the saved pocket number advanced but before release had been confirmed. One puck still held, screen pointing at the next pocket. Clean runs hid it.
I need the recovery decisions sorted before handing this over. The saved counter alone clearly isn't enough to say where the part is.
Pocket advanced, puck still in the gripper
BethBennett0759 · 2025年4月26日 22:55 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
7 条回复
What does the operator see that confirms held, placed, or unknown?
6分Only the pocket number at present. Tool feedback is logged but not shown beside the job state. Worse, the code advances on the release command, not confirmed release. That's the bit under review.
23分Then don't give them a restart recipe based on that number. It can lie.
8分Agreed. We're mapping requested action, confirmed action and unknown state separately, with controls reviewing how physical confirmation and saved state stay consistent. Ambiguous cases go to the authorised recovery process.
22分Include a stop after placement but before the saved state updates. The opposite mismatch matters too.
15分Added that case. Offline checks now keep both interruptions visibly unresolved instead of suggesting the next pocket. Practical recovery validation and operator training still need doing before release.
17分Who owns that validation? Get it named before this becomes the apparently finished job on the shelf.
19分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .