Which event details would help explain our UR5e connector-unloading stops?
Rowan_Campbell · 16 Jun 2026, 07:19 UTC
17 replies
I would send the exact message, active sequence step, event time and identified job and fixture together. Include what the operator expected to happen next. That last part is useful context, provided it is not presented as something the machine actually did
16pointsThe clip shows a held connector; the message is unreadable. Operator expected release into the tray.
9pointsKeep expected release as the operator's account then, Rowan, because seeing the connector held doesn't tell us that a release command was issued or that the receiving position was ready
10pointsUnderstood. My draft called it failed release, which the clip does not establish.
3pointsI'd correct the ticket heading as well, not only the attachment caption. Otherwise every technical person arrives expecting to diagnose the release hardware.
7pointsTheo, that matters commercially too. I have had a sales contact offer a replacement against the fault name I supplied, when what I actually needed was someone to investigate the sequence. Helpful intention, expensive guess.
16pointsI've changed the title to an unloading stop with cause unknown. No replacement requested.
5pointsCan maintenance recover records for that occurrence, or is the time too approximate to identify it? Preserve the clip either way, with its limits stated
20pointsWill, did the replacement offer get withdrawn after your correction? Our learners often think a part arriving proves the old diagnosis was right, even if nobody found the fault
9pointsYes, we paused that order before dispatch. The technical review was a separate conversation afterwards. I would not generalise from our experience, but it taught me to be more literal in my first report.
7pointsMaintenance cannot isolate the old event from my approximate time. We have agreed what to capture at another occurrence.
8pointsGood reason to leave the original clip as incomplete evidence, not retrofit it with the next event's message. Similar-looking stops can have different causes.
5pointsA later event is captured: waiting for destination confirmation, with time, fixture identity and active step linked.
7pointsWhat physical state can you establish at that destination? The message identifies a missing confirmation, but it does not decide whether the destination was occupied or the confirmation failed to reflect its state
7pointsAnd keep the relevant PLC state from that same occurrence alongside it, if available; a screen label can conceal several conditions the operator cannot distinguish by looking at the name
3pointsThe destination contact is hidden in this view. Matching PLC evidence is with maintenance; its interpretation is still pending.
6pointsThat is a narrower, honest case for support: identified destination-confirmation wait with the physical contact and PLC interpretation unresolved. It is not yet evidence that the gripper needs replacing
11pointsAdd 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.
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.