From PLC Fault Codes to Downtime Reasons: Mapping Them for OEE

Key takeaways

• A fault code is a hint, not a reason. It says which alarm fired, not always why the machine stopped.
• Map each code to a suggested reason from the line's short reason list.
• Use the first fault in a cascade, not the last one on the screen.
• Let the operator confirm or change it in one tap.
• Watch the codes that hide causes, such as the emergency stop.

PLCs raise hundreds of fault codes, and a downtime report needs 10 to 20 reasons. The bridge between them is a map: each fault code points to one suggested reason. The operator then confirms it or picks a better one, so the stop log stays both fast and true.

Fabrico, OEE and light MES software with AI cameras, logs each stop automatically and asks the operator to confirm the reason in one tap. A fault code can make that suggestion quicker. It never replaces the confirmation.

Why is a fault code not the downtime reason?

A fault code describes what the machine noticed. A downtime reason describes why the line lost time. Those are often the same, but not always.

• A low air pressure alarm may come from a leak at this machine, or from the plant's compressor.
• An emergency stop may mean a safety event, or an operator clearing a jam the fast way.
• An infeed empty alarm is not this machine's fault at all. It was starved.

Research says the same. A University of Stuttgart and Fraunhofer IAO study found that machine data alone cannot reliably tell setup time from production time. The machine tells you it stopped. A person, or the MES, tells you why.

How do you map fault codes to downtime reasons?

1. Export the fault list from the PLC or HMI, with codes and texts.
2. Sort by how often each code fires. A short list usually covers most stops.
3. Map each frequent code to one reason from the line's reason list.
4. Mark codes that need a person, such as the emergency stop, as "ask the operator".
5. Fix the OEE bucket per reason, never per fault code, so the operator never chooses it.

Keep the reason list short: 10 to 20 codes per line, because more than 30 makes the operator's choice unreliable. Our guide to downtime reason code design shows how to build it.

Which fault should count when several fire at once?

One problem often sets off a chain. A jam stops the conveyor, which trips a motor alarm, which raises a guard alarm when the operator opens the door. The screen shows the last alarm. The cause was the first.

So map the first fault in the chain, often called the first-out fault. If the PLC does not record which came first, take the earliest time stamp within a short window. Our article on PLC fault code design explains how first-out logic is built.

Worked example: one week of filler stops

Sample line (illustrative numbers, not a customer). A filler had 180 stops above the plant's cutoff in one week. Its fault codes were mapped to suggested reasons like this.

At the end of the week:

• 120 stops kept the suggested reason when the operator confirmed it.
• 35 stops were changed by the operator. Most of them were code 317, which turned out to be a leaking valve at the filler, not the plant compressor.
• 25 stops had no fault code at all, and the operator picked the reason.

Code 102, the emergency stop, fired 14 times. In 9 of those, the operator chose "jam cleared". That is a training topic and a guarding question. It would have stayed invisible if code 102 had been mapped to "safety stop" by default.

How do you keep the map honest over time?

• Review changed suggestions each month. A code the operator often changes needs a new mapping.
• Watch "Other". If more than one stop in twenty lands there, a reason is missing. The operators are not lazy.
• Update the map when the PLC program changes, because new codes appear and old ones move.
• Test the reason list: three operators code the same five stops, and you rewrite any pair they disagree on.

For keeping the reasons short and clear, see our guide to operator friendly reason codes.

Which mistakes make fault codes misleading?

• Using raw fault texts as reasons, so the Pareto has 300 bars nobody can read.
• Taking the last alarm on the screen instead of the first one.
• Mapping the emergency stop to one fixed reason, which hides what really happened.
• Letting the fault decide the OEE bucket instead of the confirmed reason.
• No confirmation step, so every guess becomes a fact in the report.

Where does Fabrico fit?

Fabrico is a computer vision enabled Manufacturing Performance Platform. OEE and light MES come first, with the reason confirmed where the stop happened.

• Automatic downtime logging from the machine signal, with start and end times.
• The operator confirms the reason in one tap, from a short list per line.
• A camera clip as evidence for a stop, where a camera watches the station.
• Losses ranked by money, so the costliest reason rises to the top.

It is the OEE layer of a light MES. You start on one line, with a baseline and a decision date agreed in advance. There is no free plan and there are no tiers: each plant gets a quote. For the shortest stops, read our guide to micro stops.

Frequently asked questions

What is the difference between a fault code and a downtime reason?

A fault code is what the PLC noticed, such as a torque alarm or low air pressure. A downtime reason is why the line lost time, chosen from the line's short reason list. One fault can point to different reasons, so the operator confirms the reason.

Can fault codes fill in downtime reasons automatically?

They can suggest them, and for many codes the suggestion is right. But some codes, such as the emergency stop, say little about the cause. Let the operator confirm or change each suggestion in one tap, and review the changes each month.

What is a first-out fault?

It is the first fault in a chain of alarms set off by one problem. A jam can trigger a motor alarm and then a guard alarm. The first one points to the cause; the later ones are side effects. Map the first fault, not the last one on the screen.

How many downtime reasons should a line have?

About 10 to 20, grouped under the big loss types. More than 30 makes the operator's choice unreliable. Many fault codes can point to the same reason, so a long fault list still fits a short reason list.

What should happen when the PLC program changes?

Update the fault code map at the same time. New codes appear and old ones can change meaning. Ask your controls engineer to share the new fault list, and check the map before the changed machine runs a full shift.

Map your fault codes with us

Bring one machine's fault list and a week of stops. We will show which codes cost most and what they really mean.

Request a demo · Contact us