Predictive maintenance
A calendar can't see a bearing starting to fail. Predictive maintenance can.
A machine that fails mid-shift and a machine serviced on a fixed calendar it didn't actually need yet are the same underlying miss: neither approach reads the machine's real condition. Predictive maintenance works off live signals (cutting load, tool life, alarm history) to catch a specific machine trending toward failure, early enough to act. Below: why that gap costs more than it should, how calendar-based scheduling differs from condition-based, what your control is already reporting, and where AI fits.
The problem
Where reactive and purely calendar-based maintenance both fall short
What an unplanned stop costs depends on your own line rate and margin, so rather than quote someone else’s figure: work out the hourly cost of downtime on your machines.
- A spindle or ballscrew fails mid-shift, and the line is down before anyone knew it was close.
- Service happens on a fixed calendar whether the machine needs it or not. A heavily used machine gets missed between intervals; a lightly used one gets serviced early for no reason.
- Nobody outside maintenance can see how close a critical machine actually is to its next failure until it happens.
- Spares get ordered after the breakdown, at rush pricing, instead of planned around a wear trend anyone could have watched.
How this differs from preventive
Predictive vs. preventive: the difference that actually matters
The two get used interchangeably, but they’re not the same thing. Here’s how the industry defines each term, before any specific tool enters the picture.
Condition-based: predictive
Service triggered by a live signal (cutting load, tool life used against target, a fault returning on a shortening interval) once it actually shows a specific machine is trending toward failure, not on a guessed interval. Catches a problem a calendar would miss entirely. This is the approach ThingConnect is built around.
Time- or usage-based: preventive
Service triggered by a calendar interval, or by run-hours/cycle counts once a machine crosses a fixed number. Simple to set up, works without any condition sensors, but it either wastes remaining service life on a lightly used machine or misses a heavily used one between scheduled visits. The comparison case predictive maintenance improves on.
The detection window
Every failure announces itself. The question is how early you hear it.
Maintenance engineering calls the first detectable change P, and the point a machine stops doing its job F. The gap between them is the only time anyone gets to plan instead of react.
A fixed service interval sits outside this picture entirely. It fires on a date, whether the machine is at P, long past it, or nowhere near it.
Component by component
What wears out, and what gives it away
Every row reads from something the control already publishes, on the same connection behind your OEE and downtime reports.
| Component | What the control reports | What going wrong looks like |
|---|---|---|
| Cutting tools | Cutting load per cycle, life used against target per tool | Load climbing cycle over cycle as the edge dulls, then a spike when it lets go. |
| Spindle & bearings | Cutting load, spindle speed, spindle-type alarms | The same program and the same tool quietly taking more load this month than last. |
| Axis drives & ball screws | Axis load, overtravel alarms with the axis that raised them | One axis pulling harder than it used to on an identical move. |
| Overall duty | Cutting minutes against operating minutes | Powered on as long as ever, but cutting for less of it. |
| Recurring faults | Alarm history, typed, per axis | The same alarm coming back on a shortening interval. |
| Thermal drift | Diagnostic readings, where the machine reports them | A diagnostic the control already publishes wandering out of its normal band. |
The first row is already on the site: tool life monitoring plots cutting load across a shift, with the load drifting up as the edge dulls.
The AI angle
What a model sees that a threshold can't
A fixed alarm limit only fires once something is already wrong. Pattern recognition works on the shape of the signal: what normal looks like for this machine, running this program, with this tool. A drift surfaces while there is still time to plan around it.
A tool going dull, before it lets go
Cutting load creeps up cycle over cycle as an edge wears. A model that has learned this tool's normal curve flags the drift before the overload spike. That is the difference between changing an insert at shift end and scrapping the part it was still in.
Normal, learned per machine
"Normal" isn't one number across a mixed fleet. It depends on the machine, the program running, and the tool in the spindle. A baseline learned per combination is what makes a deviation worth acting on instead of just noise.
How much life is actually left
A wear trend fitted across a tool's own history turns "it's worn" into "about forty hours left, plan the swap." Counting life used tells you where you are; the trend tells you how long you have.
One machine warns the others
A load signature that ran ahead of a failure on one machine can be checked against every sister machine doing the same work, so the second one gets caught early instead of repeating the first one's week.
All four read the same controller data your OEE and downtime reports already run on. No sensor kit, no separate install. When a trigger does fire, it belongs in the maintenance system, not a second inbox: downtime and condition data become work orders in MachDatum CMMS.
Related
The reports this builds on
Three reports, all reading the same controller data a condition-based trigger works from.
Questions
Before you book a demo
The same controller data the rest of the platform runs on: cutting load, spindle speed and feedrate, tool life used against target, and typed alarms carrying the axis that raised them. All of it read natively from the machine rather than from a bolt-on sensor kit or a manual log. See "What wears out, and what gives it away" above for the signal behind each component.
Downtime tracking, OEE monitoring, and machine utilization all read the same controller data; see "The reports this builds on" below. Tool life monitoring is the closest one: it already plots cutting load across a shift, tool by tool, which is the signal a condition-based trigger reads from most directly.
Preventive means time- or usage-based: service on a calendar interval or after a fixed number of run-hours or cycles, regardless of the machine's actual condition. Predictive triggers off a live condition signal. On a CNC that means cutting load, tool life used against target, or a fault returning on a shortening interval, so service happens when the equipment actually shows it's due, often with real advance warning before a hard failure. Most real maintenance programs blend both rather than picking one exclusively; this page is about the predictive half.
No. Cutting load, spindle speed, feedrate and overrides, tool life, and alarm history all come straight off the control, on the same connection that already drives your OEE and downtime reports. Anything a control doesn't publish would need its own sensing, which is worth scoping machine by machine on a call.
Talk to us
Tell us how your fleet handles maintenance today
A 30-minute call to talk through how your fleet is serviced today, which machines are worth watching first, and how downtime, OEE, and utilization tracking would read your own machines.