Start with the exact displayed message and the point in the sequence. Also say what remains active after the stop. A phone view of a stationary arm tells support very little about why it stopped.
My stop video doesn't show what support needs
MayaChen1171 · 25 Jan 2025, 03:17 UTC
17 replies
The arm holds the part above the tray. The application says waiting for inspection, and the controller screen has no visible fault message. I called it a robot fault in the ticket.
15 pointsDescribe it as a sequence waiting condition for now. No visible controller fault narrows the observation, but it doesn't establish the cause. Does the application show whether an inspection request was sent?
16 pointsThere's a request indicator lit. I can't tell whether that means it sent a request or simply entered the request step. The screen labels aren't explained anywhere.
21 pointsThat distinction belongs in the ticket. Ask for the indicator definition and the corresponding log entry. A light can show the program's intention without showing that another component received anything.
4 pointsGet the versions too. Application build, controller software and the interface library version used by this installation. Otherwise support may explain a screen from a different release, and everyone loses another afternoon.
8 pointsI've added the installed versions and corrected the fault description. The ticket now says the cause is unknown. The seller has asked for the application log around the wait.
20 pointsInclude the lead-in to that wait, not just the last line. If the system has separate logs, identify their sources and whether their clocks are aligned before combining them.
11 pointsWe spent ages chasing a stop that only followed a tray refill. What happened immediately before yours? Same part position each time, or just the same message?
-6 pointsGood distinction. A repeatable sequence state and a repeatable physical position are different clues. Both can be recorded without assuming either is the cause.
7 pointsDo not change several settings to make the next video interesting. Give support one failing example and one successful example from the same configuration, if you already have them. State any differences you know about.
10 pointsExisting examples are enough to start. I wouldn't manufacture more stops just to fill a comparison table. Ask which additional evidence the responsible engineer needs after reading the logs.
11 pointsTwo saved logs cover a success and a wait on the same tray. The stopped attempt follows a camera-service reconnect. That's an observation, not a diagnosis; I've sent both files.
22 pointsThat gives them a specific boundary to inspect. Have them explain how outstanding inspection requests are treated across a reconnect, including whether a response can be lost or attached to the wrong attempt.
22 pointsAnd ask who owns that part of the software. 'We sent it to technical' isn't a handover plan. You need the person reviewing it to know which two logs you're talking about.
12 pointsThe seller named an application engineer and confirmed receipt of both logs. They are reviewing reconnect handling. No fix yet, but the ticket finally describes a testable problem.
17 pointsBefore accepting a fix, ask what changed and how they checked both the normal inspection sequence and the reconnect case. You'll need that explanation when someone else maintains this cell.
4 pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .