Here’s the blunt version. Predictive maintenance gets sold as the destination. Condition monitoring is the road you have to build first to get there.

Most arguments about condition monitoring vs predictive maintenance are the wrong argument. You don’t pick between them. One sits underneath the other, and if the foundation isn’t there, the thing built on top is just a schedule with better marketing.

The question of condition monitoring vs predictive maintenance

Engineers and managers usually frame it as a straight choice: should we do condition monitoring, or should we invest in predictive maintenance?

That’s the wrong fork. A better question is this. Does this machine give us enough history to predict anything, and is anyone actually capturing it?

Because prediction is a claim about the future. To make that claim honestly, you need a trend. To have a trend, you need history. And on a lot of PacDrive lines, that history is quietly rolling off the log while everyone talks about forecasting.

Why “Just Buy Predictive” Falls Short

The common view treats predictive maintenance as a product. You buy the badge, you bolt it on, the machine starts telling you when a bearing will fail. That’s the pitch.

The reality is not as simple as condition monitoring vs predictive maintenance. A forecast is only as good as the data it was trained on. Feed it two weeks of readings and it will confidently tell you nothing useful. Worse, it may tell you something confidently wrong.

Legacy hardware makes this sharper. A PacDrive M controller retains a finite number of recent records. If a fault has been surfacing every few days for a month, the early evidence, the part that would show you the pattern, has already been overwritten. You can’t predict from data you never kept.

So the site that skips condition monitoring and jumps straight to “predictive” ends up predicting from a near-empty log. The average unplanned incident now runs to 81 minutes, up from 49. None of that improves if the underlying data was never captured in the first place.

The Maintenance Ladder

It helps to stop thinking in terms of two rival strategies and start thinking in rungs. Each rung needs the one below it.

Rung	What triggers the work	What it needs	Where it leaves you
Reactive	The machine stops	Nothing	You find out at 4am
Preventive (calendar)	The clock	A service schedule	You replace healthy parts and miss tired ones
Condition-based	A measured threshold (I²T, current trend, fault frequency)	Live controller data	You catch deterioration, but not its timing
Predictive	A forecast from trended history	Clean history plus a model	You get an estimate of time-to-failure

Most sites live on rungs one and two, and call rung four the goal. That’s the gap. You cannot leap from calendar servicing to a reliable forecast. The rung you’re missing is condition-based monitoring, and it’s the one that makes prediction possible at all.

Condition monitoring is not the junior version of predictive maintenance. It’s the layer that earns you the right to attempt it.

A Framework You Can Carry: Detect → Trend → Predict

Three stages. You climb them in order.

Detect. Read what the controller already exposes. Your ELAU PacDrive tracks fault codes, drive health and I²T thermal-overload values internally, right now, whether or not anyone is looking. Reading it passively and read-only is the floor of the whole thing. No new sensors, no impact on cycle time. This is where Machine Analyser® sits, pulling existing controller data without writing a single parameter back.

Trend. Keep the data long enough to see direction. A single I²T spike is noise. A rising I²T across three weeks is a drive telling you it’s working harder than it used to. The value of monitoring isn’t the snapshot. It’s the line you can draw through a hundred snapshots. And because the controller itself only holds so much, something has to retain the history the machine discards.

Predict. Only once you have clean, trended history does a forecast mean anything. Prediction is the top rung. You reach it by climbing, not by buying. Get the first two right and the third stops being a marketing word and starts being arithmetic.

Now Bring It Back to Your Estate

Forget the generic debate about condition monitoring vs predictive maintenance. Look at your own lines and work out three things.

First, which machines actually have the data depth to support a forecast, and which are running blind? Second, on your PacDrive M controllers, how much history is rolling off the log before anyone captures it? A finite record on ob solete hardware is a countdown. Third, be honest about which rung each line is really on. A lot of “predictive” programmes are rung-two calendar work wearing a rung-four label.

The economics decide themselves once you know that. An hour of downtime might interrupt £5,000 of production on one machine and £150,000 on a high-speed line. Set that against the cost of monitoring and the maths gets simple fast. Fifteen minutes of prevented downtime covers a year of proactive monitoring. The question was never whether the data is worth capturing. It’s whether anyone is capturing it before the controller forgets.

The Truth

Condition monitoring and predictive maintenance were never rivals. One is the sensing and the memory. The other is what you can finally do once you have both.

The machine has been keeping records the whole time. Predictive maintenance just means someone finally kept them longer than the machine does.

FAQ

What’s the difference between condition monitoring and predictive maintenance?

Condition monitoring measures the current state of a machine from live data such as fault codes, drive health and I²T thermal values. Predictive maintenance uses trended history from that monitoring to forecast when a component is likely to fail. Condition monitoring is the sensing layer. Predictive maintenance is the forecast you can only make once enough clean history exists.

Can you run predictive maintenance on a legacy PacDrive M controller?

Not reliably on its own. PacDrive M retains only a finite number of recent records, so the historical data a forecast depends on is overwritten before a pattern emerges. You first need to capture and retain that history externally. Once the trend data is preserved, condition-based insight is realistic, and genuine prediction becomes possible over time.

Do I need extra sensors for condition monitoring on ELAU PacDrive?

No. Your PacDrive controller already tracks fault codes, drive health and I²T values internally. A read-only tool such as Machine Analyser® reads this existing data passively, without writing to the controller or affecting cycle time. There is no hardware to install, no calibration, and no impact on machine logic or production stability.

What is I²T monitoring and why does it matter?

I²T is a thermal-overload value the drive calculates from current over time. It reflects how hard a drive is working and how close it is to a protective trip. Watching I²T as a trend, rather than a single reading, shows deterioration early, flagging a drive that is heating up before it stops the line.

How much history do you need before prediction is reliable?

Enough to establish a stable baseline and see direction, not a single snapshot. A lone spike is noise; a trend across weeks is a signal. The exact window depends on the machine and duty cycle, but the principle holds: prediction is only as good as the trended history behind it, so capturing data before the controller discards it matters most.