Everyone calls me when Fairino FR10 pauses (tray transfer)

AnilChan1071 · 2 Aug 2026, 03:24 UTC

Reply to discussion
AN
AnilChan1071
I taught our Fairino FR10 job for tray transfer with a machined sleeve in a workshop tray handling cell. Everyone can start it, but an empty pocket or interrupted run means a call to me. I don't think this is attitude. Our handover covered a clean run and left the awkward decisions out.

15 replies

RE
ReeceBaker0471
Replying to AnilChan1071

A teach-back could reveal where the handover becomes unclear. What do operators understand the restart instruction to mean when they explain it without prompts?

23 points
AN
AnilChan1071
Replying to ReeceBaker0471

@ReeceBaker0471 I tried that in a discussion. Several people read the same restart line differently. So yes, we've handed over an instruction that doesn't agree with itself.

15 points
RE
ReeceBaker0471
Replying to AnilChan1071

Rewrite that line around the visible condition, permitted next step and when to call for help. Have the responsible integrator check it, then repeat the teach-back without prompting

19 points
AN
AnilChan1071
Replying to ReeceBaker0471

@ReeceBaker0471 How do I stop teach-back feeling like a test of the operator? The wording was mine. I don't want to make that their failure.

22 points
PR
PriyaBarnes0568
Replying to AnilChan1071

On my setup, I asked people to find where my guide forced them to guess. That invited corrections instead of making them defend a wrong answer

8 points
RE
ReeceBaker0471
Replying to ReeceBaker0471

A clear recovery sheet should stop those calls. Keep the steps short and put it by the controls

22 points
BE
BenAdams0109
Replying to ReeceBaker0471

@ReeceBaker0471 Not if the system can't tell them what's physically happening. Better wording can't create a recovery path for an unknown held-workpiece state.

2 points
RE
ReeceBaker0471
Replying to BenAdams0109

You're right; I promised too much from a sheet. The guide should support defined recoveries and clearly escalate unknown states. Some calls are the correct outcome

6 points
AN
AnilChan1071
Replying to ReeceBaker0471

Our original handover only showed an empty gripper at startup. It never covered an interruption with the workpiece still held. That's a real gap.

5 points
AD
AdaBennett0738
Replying to AnilChan1071

@AnilChan1071 I'm wondering whether selecting the current pocket would allow recovery. Does the held-workpiece case mean a pocket number alone can't explain what should happen?

4 points
RE
ReeceBaker0471
Replying to AdaBennett0738

The pocket number alone doesn't establish the tool and destination conditions. Your integrator needs to define how those are confirmed and which recovery, if any, is permitted

21 points
PR
PriyaBarnes0568
Replying to ReeceBaker0471

@ReeceBaker0471 My setup had developed an informal habit of consulting whoever knew how to edit the index. A defined escalation route helped us identify uncertainty that the workaround had concealed

14 points
AN
AnilChan1071
Replying to PriyaBarnes0568

An operator also spotted that our screen and printed guide use different names for the same step. I wrote both. Lovely bit of self-sabotage.

14 points
AN
AnilChan1071
Replying to AnilChan1071

We've found a wording problem, but the reviewed recovery guidance isn't ready. I still need to support the team through the unclear cases.

12 points
RE
ReeceBaker0471
Replying to AnilChan1071

You've found something specific to improve. Keeping support available fits the unfinished guidance

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