Intermittent faults consume time because the machine often behaves perfectly when maintenance arrives. The solution is to improve evidence collection rather than repeatedly touching components until the fault disappears.
Teach operators what to capture
Operators are often present at the exact moment you are not.
The point is not extra administration; it is reducing the next uncertainty: Give them a short list: alarm text, sequence step, product, speed, temperature, what happened immediately before, and whether a reset changed anything.
A photo of the HMI before reset can be worth more than twenty minutes of description afterward.
Do not allow teach operators what to capture to depend on remembering a conversation. Put the important point where the next decision will be made: on the work order, machine note, tagged component, drawing, spare bin, or shared queue. Information stored at the point of use survives interruptions far better than memory.
Look for common triggers
Intermittent failures often correlate with heat, vibration, moisture, changeover, high speed, particular products, cable movement, or time since startup.
A reliable one-person routine turns this into a standard rather than a judgment call: Build a fault timeline and search for conditions that repeat.
A sensor dropout only after washdown points the investigation toward connectors, water ingress, and cable routing rather than logic.
When look for common triggers consumes more time than expected, do not hide the overrun. Record what created the delay – access, missing drawings, unavailable parts, unfamiliar software, contamination, damaged fasteners, or production constraints. Those delay causes are maintainability data and often justify the next improvement.
Instrument the problem
When observation is not enough, temporarily add safe measurement or logging.
The fastest way to make this useful is to attach it to the work itself: Use PLC trends, drive histories, data loggers, pressure gauges, current measurements, or video where permitted.
Capturing a 24 V dip during a fault can prove a supply problem that a handheld measurement misses between events.
For instrument the problem, distinguish the temporary operational answer from the permanent maintenance answer. The plant may need a safe recovery now, while the underlying defect still requires a scheduled repair. Write both states down so restart does not silently close the real problem.
Practical application
Take one recent maintenance event that relates to intermittent faults: the lone technician’s nightmare. Reconstruct what you knew at the beginning, before resets, part changes, or production explanations influenced the diagnosis. Then review the event through three lenses from this chapter: teach operators what to capture, look for common triggers, and instrument the problem. Write down where your real response matched the method and where it depended on memory, urgency, or luck.
Use the examples as prompts rather than scripts. For teach operators what to capture, the chapter showed: A photo of the HMI before reset can be worth more than twenty minutes of description afterward. For look for common triggers, it showed: A sensor dropout only after washdown points the investigation toward connectors, water ingress, and cable routing rather than logic. Decide on one practical change you can make before the same type of event returns – a measurement point, spare, label, note, backup, callout rule, PM task, or escalation contact.
Chapter action checklist
☐ Identify one current weakness related to
intermittent faults: the lone technician’s nightmare.
☐ Choose one change that can be implemented without new
software or budget.
☐ Decide what evidence should be recorded the next time this
situation occurs.
☐ Identify the point where you would stop and escalate rather
than continue alone.
☐ Add any resulting repair, documentation, spare, training, or
management action to the visible backlog.