I'm writing an FR5 tray-to-fixture exercise and the uninterrupted sequence is fine, but a stop between gripping, placing and saving progress leaves us unsure where the puck is; I'd like to sort the recovery on paper before anyone treats the saved pocket as permission to resume.
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.
At 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
What 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.
Gripper 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
Then 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
I'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.
Yes. Track the tray identity or agreed changeover boundary with progress. Don't let acknowledging a new tray automatically settle where the previous puck went.
Can 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.
I 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
Will the training screen distinguish missing confirmation from a confirmed failed transfer, so the operator does not interpret both as permission to repeat the movement?
It 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