Saved pocket advances while the puck may still be held
SamBennett0768 · 21 Jul 2025, 13:00 UTC
13 replies
Separate intended action, observed physical state and saved progress. A pocket number alone cannot tell you whether the puck was picked, released, or still held when the interruption happened.
10pointsAt present I save the next pocket after issuing place, not after anything confirms placement; I can see that putting the save later still leaves a different interruption gap
18pointsWhat can the real setup observe about the gripper and receiving fixture? The paper model should distinguish what is known from what you would like the operator to assume after restarting.
24pointsGripper state available, but no direct confirmation that the puck is seated in the receiver; I had been treating open fingers as proof of successful placement, which is too much
6pointsThen leave that outcome unresolved when the available evidence cannot establish it, with an authorised reconciliation route; an empty tool by itself could accompany several rather different part locations
16pointsI'd also include tray replacement during an interruption. The saved pocket could be perfectly consistent with the old tray and meaningless for the one now fitted.
12pointsYes. Track the tray identity or agreed changeover boundary with progress. Don't let acknowledging a new tray automatically settle where the previous puck went.
20pointsCan you inject stops at each transition in the offline model? That is more useful than a few random interruptions because you can show exactly which evidence exists at each recovery decision.
15pointsI have a table now for before pickup, after gripping, after the place command and after recorded completion, including a changed tray; uncertain cases wait for the controls-approved recovery rather than advancing
16pointsWho will approve that recovery and test it with operators? Good to name them now, while the table is still a design rather than a printed instruction.
14pointsControls lead with maintenance and the trainer; we're using the table for review first, no restart procedure released from this discussion
24pointsWill the training screen distinguish missing confirmation from a confirmed failed transfer, so the operator does not interpret both as permission to repeat the movement?
8pointsIt does in the draft now, and the offline cases keep uncertain placement separate from a known empty source pocket; thanks Owen, those had both been called failed
17pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .