Our UR5e tray-to-tray program picks a plastic puck, places it and advances the saved pocket. Clean runs agree with the trays; an interruption can leave the saved pocket behind or ahead of the physical work. I want a recovery design that makes uncertainty explicit before we depend on this job, not a restart that assumes the counter describes a held part.
Saved pocket disagrees with the puck after an interrupted UR5e transfer
FarahBaker0504 · 2026年7月6日 06:35 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
2 条回复
What is durably recorded before and after each physical action, with tray and attempt identities? The counter alone cannot distinguish an unperformed placement from a completed placement whose update was lost.
6分Only the next pocket is saved, after placement. The active tray choice and action stage are not durable. That leaves the completed-placement-before-save case unresolvable from our current file; we've reproduced that software gap and suspended automatic continuation while the controls owner defines retained context, observation requirements and an authorised recovery path.
11分