Key takeaways
Short answer: Generic fault codes waste diagnostic time. Well-designed codes name the specific device, the specific condition, and suggest a recovery step. The discipline costs more upfront and saves hours per fault forever. See also Downtime Reason Code Design.
"Sensor Fault" tells the operator nothing actionable. Which sensor? What kind of fault? What to check first?
Result: operator investigates from scratch. Mean time to diagnose grows. OEE suffers.
Example bad: FLT_SENSOR. Example good: FLT_PE_INFEED_LOW_LOW with description "Infeed photo-eye reading low for 2s — check lens for debris."
Consistent prefix, device, condition. Operators learn the pattern.
Document every fault code: id, description, suggested action, escalation. Operators reference; CMMS links work orders to codes.
Fault code feeds CMMS reason. Reports show top fault codes by line. Investigations target the worst.
1. Programmer-written codes without operator review. Codes make sense to the programmer; not to the operator at 3 AM.
2. No documentation. Code library lives in the programmer's head.
3. Generic catch-alls. "Other Fault" hides the actual cause.
4. Codes that change between PLC revisions. Historical data becomes unusable.
OEE Availability is dominated by downtime. Fault codes feed downtime reason categorization. Specific codes produce specific Pareto; generic codes produce a meaningless "Sensor Fault" 30% slice.
Fabrico's OEE module ingests PLC fault codes via OPC UA / Modbus, maps to reason codes, and produces Pareto reports that drive design improvements.
See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.
Controls engineering with operator + maintenance input.
Yes. Refactor on next program revision.
Variable. Tens to hundreds is normal.
Often minutes per fault. Cumulatively, hours per week.
Login
Blog
