Before anyone opens a panel, the drive has already written the incident report. Reading it properly is the fastest diagnostic act available.
The evidence layers
Fault memory holds recent trips with fault values and timestamps — and the fault value is the underrated half: F30001’s accompanying value distinguishes which phase and how hard, F07802 carries the missing-enable context. Alarm history shows what the drive complained about without stopping: temperature warnings, ID-data doubts, communication hiccups — the pre-fault biography. Counters and operating data: hours, energy, switch-on cycles — a drive with 60 000 hours and original fans has a scheduled failure pending, whatever today’s symptom is.
The workflow
- Export or photograph fault and alarm history before any reset — resets are evidence destruction.
- Timeline it: cluster the timestamps against shifts, products, weather, other machines’ events. Correlation questions (“does it only trip on the heavy recipe?”) get answered from data, not opinion.
- Compare against the machine dossier’s previous exports — a slowly rising alarm rate is a trend line pointing at a component.
- Only then form the hypothesis and pick up tools.
On machines we maintain, every visit archives the histories; over a year that becomes a health record that makes “sudden” failures embarrassingly predictable.
FAQ
The operator already reset the fault — lost cause? Fault memory survives resets (a limited depth of recent entries); power cycles are the destructive act. Go read it anyway.
Can the PLC harvest all this automatically? Yes — acyclic reads can pull fault buffers and counters into the PLC/SCADA for exactly the trending described. That is a small engineering task with outsized maintenance value.
Zone Otomasyon builds drive health trending into Zsense monitoring deployments. Predictive, not reactive.