Which FR5 state does support need when unloading waits?

YasminChen1137 · 15 Jan 2026, 10:40 UTC

Closed
YA
YasminChen1137
Our FR5 spacer-block unloading ticket is 18 days old. Seller on Alibaba wants more than the clip. I have the waiting-step name; the ordinary PLC export doesn't cover the same occurrence.

16 replies

CA
CallumAdams0099
Replying to YasminChen1137

Get the available history for that occurrence first. A matching export is more use than extending the video after the arm has already stopped.

11 points
JA
JasperArcher0377
Replying to YasminChen1137

I'm chasing a ready-condition wait on another package. Support only became useful when asked which underlying fixture condition they needed. Does your waiting step name that condition, or just say unloading?

8 points
YA
YasminChen1137
Replying to JasperArcher0377

Jasper, it says destination clear. The matching export was retained after all; destination clear is absent before the unload request.

6 points
EL
ElenaBaker0514
Replying to YasminChen1137

Was the destination actually occupied? Ask the operator who saw it, not just the person reading that signal.

12 points
TO
TomMill
Replying to ElenaBaker0514

Keep physical observation and reported condition separate until someone explains the mismatch.

6 points
PA
PatBlair
Replying to TomMill

Tom, yes, though an occupied destination might mean no mismatch at all. It could be waiting exactly as intended and the real problem is how that state is explained to the operator.

6 points
ZA
ZaraBrown0917
Replying to ElenaBaker0514

Can the operator see the receiving pocket from the normal loading position? I've been caught assuming that because the phone camera could.

20 points
TO
TomMill
Replying to PatBlair

Agreed, Pat. I should have said possible mismatch.

25 points
YA
YasminChen1137
Replying to ZaraBrown0917

Elena and Zara, the operator says a block remained in the receiving pocket, hidden from his usual position. The wide still in our clip shows it too. He thought the wait meant the robot hadn't gripped.

9 points
CA
CallumAdams0099
Replying to YasminChen1137

Then don't order gripper parts on the strength of that clip. How did the block come to remain there?

7 points
EL
ElenaBaker0514
Replying to YasminChen1137

Yasmin, what wording does the operator screen use at that point? A correct condition with the wrong label can send every caller down the same path.

0 points
YA
YasminChen1137
Replying to ElenaBaker0514

Screen says 'transfer not complete'. Support traced the retained block to an earlier interrupted unload; this capture starts afterwards. We still don't know what interrupted that earlier transfer.

8 points
JA
JasperArcher0377
Replying to YasminChen1137

That wording is doing you no favours. Ask for the occupied destination and the undecided earlier transfer to be explained separately. Otherwise they'll rename the wait and everyone will assume the original interruption was repaired.

9 points
PA
PatBlair
Replying to YasminChen1137

The operator's explanation is useful evidence about the screen, not an embarrassing mistake to bury. Thank you for including it. That's precisely the misunderstanding a handover should catch.

24 points
YA
YasminChen1137
Replying to JasperArcher0377

Revised screen wording passed our operator walkthrough: he identified the occupied destination and called for the agreed recovery help. No gripper order. The older interruption stays on the ticket as unexplained.

11 points
ZA
ZaraBrown0917
Replying to YasminChen1137

Did they improve visibility of the receiving pocket too, or is the screen still his only useful view?

18 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .