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