Connector loading waits at an empty destination

RosaBrown0901 · 9 Feb 2026, 18:01 UTC

Closed
RO
RosaBrown0901
I want to show support why our UR5e waits when the destination looks empty. My video shows the tray and the wait message, but not the destination status at the moment it stopped. The seller has asked for more information without saying which signal they need.

15 replies

FA
FarahBarnes0591
Replying to RosaBrown0901

Ask their technical contact to name the condition behind that wait message. Our screen once carried the wrong recipe label, which made a real receiver wait sound like a different problem. The words alone sent us in circles.

25 points
LI
LinBrown0879
Replying to RosaBrown0901

Does the job think the destination is empty, Rosa, or only the person looking at it?

6 points
HA
HarishBell0663
Replying to RosaBrown0901

I'd also ask who clears a completed destination in the normal changeover. We had somebody removing finished parts while the application was still waiting for the agreed exchange confirmation. Empty tray, busy computer.

14 points
RE
RebeccaCarter1039
Replying to HarishBell0663

Harish, possible, but don't turn the loader into the suspect before Rosa knows which condition is missing. A half-written changeover sequence can leave them doing exactly what the instruction says.

1 points
RA
RaviBrown0911
Replying to RosaBrown0901

Get the preceding states retained with the stop. Our newer capture finally includes that interval; the original short export missed it entirely.

23 points
NI
NinaChan1110
Replying to RosaBrown0901

Can the operator read the destination identity from their normal position? A screen label that only the programmer recognises will not help much.

17 points
RO
RosaBrown0901
Replying to LinBrown0879

Lin: job says occupied, although that pocket is physically empty. Harish: the instruction includes exchange confirmation, and the loader followed it. Support has now named the retained destination-status field they want with the job identity.

0 points
CH
ChenAli0181
Replying to RosaBrown0901

Then compare which destination that exchange confirmation cleared. It might be correctly recorded against a different tray job. I would not ask the operator to repeat it blindly while the ownership is unclear.

19 points
HA
HarishBell0663
Replying to RebeccaCarter1039

Rebecca, agreed. Rosa's answer makes the distinction important. I was describing our case, not accusing her loader of skipping something.

-7 points
RO
RosaBrown0901
Replying to NinaChan1110

Nina, destination names were abbreviated and too similar. The retained trace also shows exchange clearing the previous tray job, while the active job keeps its occupied state. Programmer is checking that mismatch.

10 points
FA
FarahBarnes0591
Replying to RosaBrown0901

That sounds painfully familiar in the wording, although the job-state mismatch is your own finding. Keep both in the correction: clearer names won't fix which job receives the confirmation.

12 points
RE
RebeccaCarter1039
Replying to RosaBrown0901

Will the revised screen let the loader see the active job before confirming the exchange, Rosa? I'd want that answer from someone using it, not just someone who wrote it.

20 points
RO
RosaBrown0901
Replying to RebeccaCarter1039

Revision ties exchange confirmation to the active destination identity and rejects the old job's confirmation. Offline tests cover both cases. The clearer names passed a walkthrough with our loader, who spotted the mismatched example unaided.

7 points
RA
RaviBrown0911
Replying to RosaBrown0901

Has that correction reached the installed station, or is it still the tested revision waiting to go in?

18 points
RO
RosaBrown0901
Replying to RaviBrown0911

Installed and checked with the integrator. Two normal tray exchanges completed, and the mismatched-job test held for review instead of clearing another destination. This ticket is closed. Thanks for asking about the condition behind the message, Farah.

9 points

Discussion closed

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