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_PE101_INFEED_BLOCKED with description "Infeed photo eye PE101 blocked for more than 2 s, check the lens for debris and the chute for a jam."
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 through its PLC connectivity, 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.
Stop chasing this fault by hand. Fabrico logs each stop against the machine's history, so a repeating fault shows up before it becomes a hard line stop, and the team can open a prioritized work order with the stop itself captured on video wherever a camera covers the line.
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.
"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_PE101_INFEED_BLOCKED with description "Infeed photo eye PE101 blocked for more than 2 s, check the lens for debris and the chute for a jam."
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 through its PLC connectivity, maps to reason codes, and produces Pareto reports that drive design improvements.
Capture the first out. When one failure trips a chain of interlocks, the operator sees ten faults and has to guess which came first. Latch the first fault in each sequence with a timestamp and show it on the HMI as the first out, so the code that reaches the CMMS is the cause rather than the last symptom.
Never reuse a code number. Treat the code list like a part number list: once a code is released, retire it rather than reassigning its number to a different condition, and issue a new number instead. Years of downtime history then stay comparable across program revisions.
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.