I cannot diagnose our UR5e sleeve-unloading stops from this clip

JaneAbbott0075 · 26 Jul 2026, 14:40 UTC

Reply to discussion
JA
JaneAbbott0075
I've had a support request open with our Alibaba seller for 12 days over intermittent UR5e sleeve-unloading stops. They asked for more information after my phone video. What should I collect so we can distinguish a sequence wait from something failing, rather than just film the stationary arm again?

14 replies

GA
GabrielAbbott0018
Replying to JaneAbbott0075

Does your video show the message when the stop happens?

0 points
JA
JaneAbbott0075
Replying to GabrielAbbott0018

It starts after the arm has stopped. I can see the sleeve, but the display isn't readable. I have no exact message for that occurrence.

10 points
TH
ThomasBarnes0538
Replying to JaneAbbott0075

Send the installed software and program references now. Ask support which event export they need, then match the next capture to its timestamp and active step.

10 points
TH
TheoAllen0323
Replying to JaneAbbott0075

What's the operator's account of the few seconds before your clip, Jane? Doesn't need to be a diagnosis. On shift I'd want their own description beside the files, especially if the stop followed a tray change or manual intervention.

15 points
JA
JaneAbbott0075
Replying to TheoAllen0323

The operator says it happened during the normal unloading sequence, with no recent manual intervention they recall. I've added that as recollection and requested the export instructions. Configuration references have gone to support.

9 points
JA
JamieCarter0991
Replying to JaneAbbott0075

Keep normal sequence as context, not proof that every earlier stop was the same event.

23 points
GA
GabrielAbbott0018
Replying to JaneAbbott0075

Did support say which additional information was missing, beyond asking for details?

22 points
JA
JaneAbbott0075
Replying to GabrielAbbott0018

They've now named the log export and asked for the active step and fixture state from the same occurrence. We haven't captured another stop yet, so those are still outstanding.

15 points
TH
TheoAllen0323
Replying to JaneAbbott0075

Give that request to the person who will actually be there, then agree who forwards the material. Otherwise it sits in your email while the shift sees another pause and assumes support already has enough video.

8 points
TH
ThomasBarnes0538
Replying to JaneAbbott0075

Preserve the physical observation as well as commanded fixture state. The command can be present while the condition it requests remains unconfirmed.

16 points
JA
JaneAbbott0075
Replying to ThomasBarnes0538

We have a matched capture now. The screen identifies a waiting step, and support has asked our controls owner to compare its expected fixture feedback. That doesn't yet establish which part of the system is responsible.

1 points
JA
JamieCarter0991
Replying to JaneAbbott0075

Exactly. A named wait gives you a question to investigate, not a failed component to order.

7 points
JA
JaneAbbott0075
Replying to TheoAllen0323

Thanks, Theo; the shift handoff meant the log and physical view arrived together this time. Controls is still preparing the comparison. I've left the older clip unclassified rather than giving it the new wait label.

17 points
GA
GabrielAbbott0018
Replying to JaneAbbott0075

Has the seller's ticket description been updated too? The first diagnosis can linger in its title.

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