It advances before placement confirmation. So after a stop, the number can describe the next intended pocket rather than a transfer we know finished. That's on my sequence.

Use an offline stage model to distinguish transfer progress from confirmed completion. Your integrator should define reconciliation between retained state and physical tool and pocket conditions, including what happens when those conditions are unknown.

Would correcting the position of the index update fully address this? I had hoped the problem was limited to that single sequencing error.

Persisting the transfer stage as soon as each action finishes should let the recovery sequence determine the correct point to resume.

There's still a gap between the physical action and the save. A stop in that gap leaves you guessing, just with a more descriptive variable.

@CalebBaker0493 I overstated what persistence provides. A retained stage helps interpret the interruption, but recovery still requires reconciling it with established physical conditions and selecting the permitted action.

@GabrielAdams0105 On my setup, one index could mean either 'still carrying' or 'already placed'. Giving those states names made the design discussion much less circular.

Our test actually stopped with the workpiece held while the display said to start another pickup. The recovery message was confidently wrong.

Can recovery infer a held workpiece from the gripper's closed indication, or does that indication fail to establish actual possession?

It depends on what your installed sensing actually establishes. A closed indication isn't automatically proof of a held workpiece; document confirmed, empty and unknown conditions with your integrator.

The destination worries me too. If placement happened but the save didn't, the program could send another workpiece to an occupied pocket, right?

@OwenCarter1008 That's a possible mismatch to include in the design. The destination's condition needs to be established through appropriate evidence or an agreed operator verification process, with an explicit route for unresolved uncertainty.

And don't relabel 'unknown' as 'empty' because that makes the next branch easy. Unknown needs to survive all the way to the recovery decision.

@CalebBaker0493 On my cell, we kept completed quantity separate from pocket and stage. A nice-looking batch total wasn't enough to explain a half-finished transfer.

@AishaBell0692 How did you explain that without giving operators three mysterious numbers? I'd like the screen to help someone decide, not look busier.

@OwenCarter1008 On my setup, the display described the known condition and the permitted next step. We kept the diagnostic detail available without making operators interpret raw state values.

Should the state model assume ordinary stops, program restarts and loss of power preserve variables in the same way, or are those separate cases?

Different interruption types need their own retention assumptions. Use documentation for the installed controller and a planned supervised verification to establish what survives ordinary stops, program restarts and power loss.

I've settled on explicit stages plus physical-state reconciliation for the redesign. Any production use depends on integrator review and successful interruption checks; moving the index update alone isn't my fix.