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
Which event details would help explain our UR5e connector-unloading stops?
Rowan_Campbell · 16 Jun 2026, 07:19 UTC
17 replies
The clip shows a held connector; the message is unreadable. Operator expected release into the tray.
9 pointsKeep 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
10 pointsUnderstood. My draft called it failed release, which the clip does not establish.
3 pointsI'd correct the ticket heading as well, not only the attachment caption. Otherwise every technical person arrives expecting to diagnose the release hardware.
7 pointsTheo, 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.
16 pointsI've changed the title to an unloading stop with cause unknown. No replacement requested.
5 pointsCan maintenance recover records for that occurrence, or is the time too approximate to identify it? Preserve the clip either way, with its limits stated
20 pointsWill, 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
9 pointsYes, 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.
7 pointsMaintenance cannot isolate the old event from my approximate time. We have agreed what to capture at another occurrence.
8 pointsGood 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.
5 pointsA later event is captured: waiting for destination confirmation, with time, fixture identity and active step linked.
7 pointsWhat 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
7 pointsAnd 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
3 pointsThe destination contact is hidden in this view. Matching PLC evidence is with maintenance; its interpretation is still pending.
6 pointsThat 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
11 pointsAdd 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.