The real skill in technical support is not fixing problems. It is identifying the correct problem.
A common pattern
Many support cases start with:
"The camera is broken."
After investigation, the camera is fine. The root cause is somewhere else entirely - lighting, a loose cable, a process change upstream, or an operator workflow that quietly changed last week.
A case walked end to end
Report: "The camera randomly stops working a few times per day. Please send a replacement."
- What does "stops working" mean, exactly? Not a rhetorical question - it turned out to mean "the inspection result screen freezes". Already we have moved from camera to anything in the chain.
- When did it start? "A few weeks ago." What else happened a few weeks ago? A new machine was installed on the adjacent line.
- Is there a pattern in the timestamps? The freezes clustered around shift starts. Shift starts are when the neighboring machine runs its homing cycle.
- What does homing do? It draws a large inrush current - on a circuit shared with the camera's network switch. The switch brownout dropped the camera link for half a second; the software's error handling then hung waiting for a frame.
The fix was an independent power feed for the switch and a software timeout. The camera - the named suspect - was never the problem. A replacement camera would have "fixed" it for exactly as long as the next coincidence.
Questions that separate symptom from cause
- What changed, and when? (Something always changed. "Nothing changed" means nobody knows what changed.)
- Does the timing correlate with anything - shifts, batches, weather, the machine next door?
- What does the failure look like in data, not in description?
- If the named component were perfect, could this symptom still occur? (Usually: yes.)
The rule
Symptom does not equal cause.
This applies everywhere, not just in machine vision. The fastest fixers are the people who resist the obvious explanation long enough to confirm it.