Your machines are already telling you they're about to break. You're just not listening.

Every CNC machine, compressor, pump, and HVAC unit on your factory floor generates continuous data. Temperature readings. Vibration levels. Pressure fluctuations. Runtime hours. This data is a running commentary on machine health — if you know how to read it.

Condition-based monitoring is the practice of collecting that data, setting rules around it, and letting the system take action when something goes sideways. No guessing. No waiting for the operator to notice a strange noise. Just data-driven maintenance decisions.

Here's how it works.

What You're Actually Monitoring

Condition-based monitoring tracks real, measurable parameters from your machines:

  • Temperature — bearing housings, motor windings, hydraulic fluid, coolant systems
  • Vibration — amplitude and frequency, which indicate bearing wear, misalignment, or imbalance
  • Pressure — hydraulic systems, compressed air, process fluids
  • Runtime hours — total operating time, which correlates with wear and degradation
  • Flow rate — coolant flow, lubricant flow, process throughput
  • Electrical parameters — current draw, voltage, power consumption
  • Custom parameters — anything your machines can report via OPC-UA, Modbus, or MQTT

Each parameter gets tracked over time. Not just the current reading, but the full history. This history is what makes condition-based monitoring powerful — it's not about one reading, it's about the trend.

How Condition Triggers Work

A condition trigger is a simple rule: "if this parameter meets this condition, do this."

Here's the anatomy of a trigger:

Parameter: What you're measuring (e.g., spindle bearing temperature)

Operator: How you're comparing (greater than, less than, equal to)

Threshold: The value that triggers action (e.g., 85°C)

Duration: How long the condition must persist (e.g., 30 minutes)

Action: What happens when the trigger fires (e.g., create a corrective maintenance ticket)

Priority: How urgent the resulting ticket is (e.g., High)

Cooldown: How long before the same trigger can fire again (e.g., 24 hours)

Let's walk through a concrete example.

Example: Bearing Temperature on a CNC Spindle

You have a CNC machine where the spindle bearing normally runs at 72°C. You've been tracking the temperature for 3 months, so you know the baseline. You set up a trigger:

  • Parameter: Spindle bearing temperature
  • Condition: Greater than 85°C
  • Duration: Sustained for 30 minutes
  • Action: Create corrective maintenance ticket
  • Priority: High
  • Cooldown: 24 hours

Here's what happens:

Normal operation. Temperature reads 72°C. Trigger checks every time new data arrives. Condition not met. Nothing happens. Zero noise.

Temperature rises. Coolant system starts degrading. Temperature climbs to 82°C, then 86°C. The condition is met (86 > 85). But the 30-minute duration clock starts.

Condition sustains. For the next 30 minutes, the temperature stays above 85°C. The system checks: 80% of readings in the window must meet the condition. They do.

Trigger fires. A corrective maintenance ticket is automatically created with all the context — the parameter name, current value (86°C), the threshold (85°C), and how long it's been sustained (30 minutes). The ticket is assigned based on your rules.

Cooldown activates. For the next 24 hours, this trigger won't fire again. Even if the temperature stays above 85°C. This prevents alert fatigue — you don't want 15 tickets for the same condition.

The technician sees the ticket, inspects the machine, and finds the coolant issue before the spindle is damaged. The fix takes 20 minutes. The machine never goes down.

Immediate vs. Sustained Triggers

Not every condition needs a 30-minute wait. Some things are urgent right now.

Immediate triggers fire the instant the condition is met. Use these for critical parameters where even a brief exceedance is dangerous — like motor winding temperature approaching maximum rating, or hydraulic pressure exceeding safe limits.

Sustained triggers require the condition to persist for a specified duration before firing. Use these for parameters that fluctuate normally — like bearing temperature that might spike briefly during startup but should settle down within minutes.

The 80% rule applies to sustained triggers: 80% of readings within the duration window must meet the condition. This filters out brief spikes and noise. A single temperature spike at 86°C for 2 minutes won't trigger an alert. A sustained temperature above 85°C for 30 minutes will.

Preventing Alert Fatigue

The biggest risk with any monitoring system is alert fatigue — too many notifications, too many tickets, and eventually people stop paying attention.

OpexMX prevents this with three mechanisms:

Cooldowns. After a trigger fires, it can't fire again for the cooldown period. This prevents duplicate tickets for the same ongoing condition.

Deduplication. The system checks for existing open tickets for the same trigger and asset before creating a new one. If there's already an open ticket from this trigger in the last 24 hours, it skips.

Threshold tuning. The system monitors how often each trigger fires and suggests threshold adjustments. If a trigger fires 50 times in a week, the threshold is probably too aggressive. If it never fires, it might be too loose. The system flags these patterns for human review — it doesn't auto-adjust.

The Pareto of Triggers

After running condition triggers for a few weeks, you'll start seeing patterns. Some triggers fire often. Some assets trigger repeatedly. This is valuable data.

OpexMX's Pareto analysis shows you:

  • Which triggers fire most frequently (ranking by count)
  • Which assets are most affected (assets associated with each trigger)
  • Trends over time (is a trigger firing more or less than last month?)

This data tells you two things:

  1. Where to focus reliability efforts. If the "Bearing Temp > 85°C" trigger fires 20 times a month across 5 assets, that's a systemic issue. Maybe those bearings are underspecified. Maybe the operating environment is hotter than designed. The trigger data surfaces the pattern so you can investigate.

  2. Whether your thresholds are calibrated. A trigger that fires 5% of the time is probably well-calibrated. A trigger that fires 80% of the time is just noise. Use the Pareto to tune.

Condition-Based vs. Calendar-Based: They Work Together

Condition-based monitoring doesn't replace your preventive maintenance schedule. It supplements it.

Keep your calendar-based PMs for routine tasks — lubrication, filter changes, visual inspections, safety checks. These are proven intervals that maintain baseline reliability.

Add condition triggers for the parameters that indicate degradation between PM intervals. Bearing temperature. Vibration amplitude. Hydraulic pressure. These are the early warning signs that your calendar-based schedule can't detect.

The result: you still do routine PMs on schedule, but you also catch emerging issues between intervals. Fewer surprises. Fewer breakdowns. More control.

Getting Started with Condition Monitoring

You don't need to monitor every parameter on every machine. Start small:

  1. Pick 3-5 critical assets — the ones where unplanned failure hurts most
  2. Identify 2-3 parameters per asset — temperature, vibration, and pressure are the most common
  3. Set conservative thresholds — start high, tighten as you learn the baselines
  4. Run for 30 days — collect data, review what fires, adjust
  5. Expand gradually — add more assets and parameters as confidence grows

Within 90 days, you'll have a monitoring program that catches real issues before they become real failures.

Set up your first condition trigger with OpexMX — and start listening to what your machines are already telling you.