Our tray index stops matching reality after a restart

CalebBaker0493 · 30 Apr 2026, 13:55 UTC

Reply to discussion
CA
CalebBaker0493
My Fairino FR10 program picks a rigid molded spacer, places it and advances the pocket during indexed tray loading in a small fixture loading area. Clean runs work. After a stop between actions, the saved pocket sometimes doesn't match reality. We've 90 planned, and I want recovery sorted before normal production depends on it.

15 replies

RA
RachelAli0261
Replying to CalebBaker0493

Can you locate the index update against the placement confirmation in the recorded sequence? The actual ordering will help identify what the saved value represents at an interruption.

20 points
CA
CalebBaker0493
Replying to RachelAli0261

The trace shows my index update occurs before placement is confirmed. That means the retained number can identify an intended next pocket without establishing that the preceding transfer completed.

13 points
RA
RachelAli0261
Replying to CalebBaker0493

@CalebBaker0493 Map the transfer stages offline, with an agreed completion confirmation. Have your integrator define how saved state is reconciled with tool and pocket conditions; unknown conditions need an explicit recovery route.

22 points
CA
CalebBaker0493
Replying to RachelAli0261

So just moving the increment isn't enough? I'd hoped this was one badly placed line, which would've been embarrassing but convenient.

17 points
RA
RachelAli0261
Replying to CalebBaker0493

Save the stage immediately after every action and you should always know where to resume.

18 points
CA
CarlaBrooks0836
Replying to RachelAli0261

Updating a stage after an action doesn't eliminate the interval between the physical event and persistence. An interruption there can leave the saved stage inconsistent with reality.

12 points
RA
RachelAli0261
Replying to CarlaBrooks0836

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

17 points
CL
ClaraBell0611
Replying to RachelAli0261

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

17 points
CA
CalebBaker0493
Replying to ClaraBell0611

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

12 points
SA
SaraAdams0113
Replying to CalebBaker0493

Wouldn't a grip signal settle that? Or can 'gripper closed' mean it's holding nothing?

17 points
RA
RachelAli0261
Replying to SaraAdams0113

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.

7 points
CA
CalebBaker0493
Replying to RachelAli0261

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

4 points
RA
RachelAli0261
Replying to CalebBaker0493

Yes, that's an ambiguity your recovery design must cover. Establish destination condition through suitable evidence or a defined operator procedure, with escalation when it can't be confirmed.

14 points
CA
CalebBaker0493
Replying to RachelAli0261

The early index update explains part of the mismatch. I still need reviewed recovery handling for uncertain physical states, so this isn't ready for normal production.

10 points
RA
RachelAli0261
Replying to CalebBaker0493

Finding the early update helps, but the uncertain states still need a recovery decision.

23 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.