“It is broken,” “the PLC is confused,” and “it keeps tripping” are not diagnostic statements. Good troubleshooting begins when vague complaints are translated into observable behavior.
Five Principles to Use in the Field
- Use neutral language. Describe what the machine does and does not do without naming a cause. “Conveyor output is commanded but motor current remains zero” is better than “the starter is bad.”
- Include sequence position. A machine that never starts is different from one that starts and stops at step seven. Sequence position sharply narrows possible causes.
- Describe reproducibility. Does it fail every cycle, only with one product, only after warming up, or only after a changeover? Patterns are evidence.
- Compare expected and actual states. Troubleshooting is the study of differences. What should be ON, moving, pressurized, detected, or acknowledged at this point—and what actually is?
- Separate primary from secondary alarms. A low-pressure alarm may trigger ten downstream “not ready” alarms. Follow the first meaningful loss, not the longest alarm list.
Pressure Mistakes to Avoid
- Using a component name as the symptom: “bad prox.”
- Chasing the most recent alarm instead of the first causal event.
- Ignoring the step or state in which the sequence stopped.
- Failing to note whether a manual command works when automatic does not.
A Practical Breakdown Method
- Write the complaint in the operator’s words.
- Rewrite it as an observable symptom.
- State the expected machine state.
- State the actual machine state.
- Identify the earliest confirmed difference.
- Use that difference to choose the next system boundary to test.
Scenario: The complaint is “the robot is not receiving parts.” Observation shows the upstream conveyor runs, the stop gate is down, and the gate solenoid output is OFF. The PLC sequence is waiting for “part present at nest,” which is falsely ON due to a dirty sensor. The neutral symptom led to the real dependency instead of a robot investigation.
Train This Before the Next Callout
Choose one critical machine you know and apply the ideas from this chapter while it is healthy. For turn the complaint into a technical symptom, write down the normal sequence, the key evidence you would want to preserve, and the first three checks you would make if the machine stopped. Then compare your plan with the electrical drawings, PLC diagnostics, maintenance history, and the experience of another technician. A ten-minute rehearsal in daylight can remove several minutes of confusion at night.
3 AM Rule: A precise symptom is already half a diagnosis because it tells you where reality first stopped matching the sequence.
Chapter Checklist
- Can I describe the symptom without naming an unproven cause?
- Have I preserved the evidence that could disappear after a reset or restart?
- Do I know which system boundary I am testing next and why?
- Have I kept safety controls and temporary changes visible and controlled?
- Can I explain my current facts, hypothesis, and next action in under thirty seconds?