What Your Crusher Screens Aren't Telling You

The crusher screen in your control room shows tonnes-per-hour and a green status light. That's the screen the operator sees. It tells them the plant is running. It doesn't tell them how the plant is running, or whether it will keep running in three hours.

There are three other screens — three other layers of data — that the HMI isn't showing you. Not because the data doesn't exist. It does. It's sitting in your PLC tag database right now, updating every scan cycle. It's buried in your downtime logs, coded as a single flat reason that strips out half the information. It's in the handover conversation that happened at 18:00 and will never be written down.

This article is about those three layers. What they contain, why your current setup hides them, and what you'd see if you exposed them.

Layer 1: The PLC Tag Layer

Every Allen-Bradley or Siemens PLC running your crusher circuit is logging hundreds — sometimes thousands — of tags per second. Motor current. Oil temperature. Bearing vibration. Belt scale weight. Hydraulic pressure. The tag database is a real-time picture of the machine's health, updated faster than any operator can read.

The HMI shows you a summary. A green light. A number. It was designed that way — the HMI's job is to give operators clear, actionable displays, not data archaeology tools.

But here's what gets lost: trend data before a trip event.

Take lube system trips. The trip happens at a point in time — an alarm fires, the crusher stops, someone runs to check the oil level. But the trip didn't happen at that moment. The oil temperature started climbing three minutes earlier. That climb is in the tag history. An Allen-Bradley Logix controller logs it, a Siemens S7 logs it, and almost no one is reading it systematically.

Same story with motor current on your secondary cone. A healthy motor running a healthy crushing chamber has a current signature that sits in a predictable band. When the chamber geometry changes — worn liners, oversize feed, tramp iron compaction — the current drift starts before the performance drop. You're looking at real-time values. The drift pattern is in the trend.

Belt scale calibration is another one. Calibration drift on a belt scale typically accumulates week-over-week. A scale that read accurately in January is often 3–7% off by April. That drift is visible in the tag history if you plot tare weight checks over time. Most sites never do.

What you'd see if you exposed this layer: a timeline of every tag that moved outside its normal range in the 10 minutes before a trip. A drift chart that shows you which scales need recalibration before they distort your OEE numbers. Motor current trending that tells you a liner changeout is coming two weeks before throughput drops.

The data is already there. Collecting it isn't the problem.

Layer 2: The Downtime Reason Layer

"Belt trip" is one of the most useless pieces of information in a mining shift report.

Not because belt trips don't matter. They obviously do. But "belt trip" as a downtime reason tells you nothing about why the belt tripped, which means it tells you nothing about how to prevent the next one. It's a symptom coded as if it were a cause.

The real question is: belt trip caused by what?

• Chute blockage from oversize feed — a material handling problem
• Tramp metal breach — a detection or removal problem
• Operator clearing a jam — a procedure or training problem
• Belt tracking issue — a maintenance problem
• Conveyor overload — a feed rate control problem

Each of those has a completely different root cause, a different responsible team, and a different prevention strategy. When you roll them all up as "belt trip," your OEE improvement program has nothing to work with.

A structured reason hierarchy fixes this. The top-level categories are broad — Mechanical, Electrical, Process, External, Planned. Each category branches into specific failure modes. Each failure mode optionally branches into sub-causes. The operator picks from the tree at shift end or at event closure. They're not writing free text. They're selecting from a controlled vocabulary that makes aggregation meaningful.

A good reason tree for a SAG-and-crusher circuit might look like this:

Unplanned Downtime
├── Mechanical
│   ├── Crusher
│   │   ├── Liner wear
│   │   ├── Oil system fault
│   │   └── Hydraulic fault
│   └── Conveyor
│       ├── Belt damage
│       ├── Belt tracking
│       └── Drive fault
├── Process
│   ├── Feed quality
│   │   ├── Oversize
│   │   └── Wet/sticky feed
│   └── Tramp metal
├── Electrical
│   ├── Instrument fault
│   └── Power supply
└── Operator
    ├── Jam clearance
    └── Misoperation

With this structure, you can answer questions that matter: What percentage of our conveyor stops are process-caused versus mechanical? Is tramp metal frequency correlated with which pit is being blasted? Which crusher is accumulating the most oil system events this quarter?

Without structure, your OEE number is a fiction. You know what it is. You can't move it because you can't see what's inside it.

Layer 3: The Handover Layer

Shift A finishes at 18:00. Shift B starts at 18:00. The handover happens in the crib room, or at the control desk, or in a five-minute conversation at the gate.

What gets passed across:

• The stuff that's obvious — what stopped, what's running
• The stuff the outgoing operator remembers to mention
• The stuff they think the incoming operator probably already knows

What gets lost:

• The noise on the secondary that started at 14:00 and hasn't tripped anything yet
• The open work order on the chute liner that maintenance said they'd look at "tomorrow"
• The lube schedule status — was the weekly check done this shift or not?
• The feed rate adjustment that was made at 16:30 and why

The incoming shift spends the first 30–60 minutes piecing together plant state from the previous shift's memory, the whiteboard, the logbook (if it's been written up), and their own observation. That's dead time on every shift, every day, 365 days a year.

Digital handover captures this in a structured form. Not a free-text notes field — those accumulate noise and get ignored. A structured handover has defined sections: active alarms, open work orders, process state at shift end, deferred maintenance, known anomalies, and a notes field for anything else. The outgoing operator fills it in. The incoming operator signs off that they've read it.

The result: Shift B starts knowing what Shift A knew. The noise on the secondary gets actioned rather than rediscovered. The work order doesn't get lost. The lube schedule doesn't slip because no one was sure if it was done.

Thirty minutes saved per shift, every shift, at every site. That's not a small number.

What Comes Next

These three layers — PLC tag trends, structured downtime reasons, and digital shift handover — are not new concepts. The Pilbara's major operators have been building versions of this for years. What's changed is the cost of implementation and the time to value.

RATECH can show you all three layers running on a live dashboard for your plant in four weeks. No ripping out your existing HMI. No new PLCs. A read-only connection to what you already have, surfaced in a way your operators and planners can actually use.

The pilot is free. If it doesn't show you something you didn't already know about your plant, there's nothing to discuss.