Why Intermittent Problems Are Different

I have spent more hours than I care to count standing at a machine, waiting for an intermittent problem to reappear. The part that makes these issues so frustrating is obvious: if the fault fired every cycle, I could isolate it in an afternoon. But when a tool burns up on one part, runs fine for the next ten, and then burns up again on part twelve, you are no longer troubleshooting a single event. You are chasing a condition that crosses some invisible threshold only part of the time.

Most of my early mistakes came from treating intermittent problems like continuous ones. I would change the insert grade, adjust the coolant pressure, or tweak the feed rate after the first bad part, only to have the problem vanish for a week and come back twice as hard. The root cause was never the thing I changed. It was a variable I was not measuring, one that drifted in and out of a bad zone.

The fundamental shift for me was accepting that I cannot solve an intermittent problem until I can describe what is different about the moments it occurs. That requires data, patience, and a structured method.

The Data Collection Approach: Log What Changes

When a problem only shows up occasionally, your memory is not reliable enough. I learned to keep a simple log alongside every intermittent-troubleshooting case. The goal is not to record every number the machine spits out. The goal is to capture what changed before the problem appeared.

Here is the template I use. I print a stack of these and keep them on a clipboard at the machine.

TimestampPart #Problem ObservedCoolant Temp (°C)Spindle Speed (RPM)Feed Rate (mm/min)Material Heat CodeOperator Notes
08:1504724.2350045B721Normal startup
09:42052Burn mark on land26.8350045B721Coolant felt warm
11:1005825.1350045B722Fresh bar loaded
13:30064Drill chatter, bore off-size31.2350045B722Hot afternoon, chiller cycling
14:0506527.4350045B722Chiller caught up

I fill in the columns that are easy to get automatically (time, part number, coolant temperature from the machine readout) and add one or two manual observations. The pattern that revealed itself in this example was coolant temperature climbing above 30 °C, which correlated with every bad part. Without the log, I would have sworn the problem was material-related.

For more detail on designing a data collection plan that fits your shop floor, see the guide on data collection for troubleshooting.

Common Intermittent Causes

Over the years I have seen the same handful of culprits surface again and again. They share one trait: they fluctuate slowly, so the machine runs inside spec most of the time and only drifts out when conditions stack up.

CauseWhat to Look ForHow to Test
Coolant temperature fluctuationChip packing, built-up edge, inconsistent surface finishLog coolant temp at headstock and return every 15 minutes; check chiller cycle timing
Material hardness variationSpindle load jumps between bars or between front/middle/back of same barSpark test or portable hardness test at each end of a suspect bar; review mill certs
Guide bushing wear progressionGradual increase in ovality, worsening on long runsMeasure bushing ID at 3-month intervals; compare bore roundness to bushing wear pattern
Spindle warm-up / thermal growthFirst-part-of-the-day defects that disappear after 30 minutesRun a warm-up cycle and document bore position at 5-minute intervals until stable
Chip evacuation blockageRandom torque spikes, drill wander, no clear patternBorescope the chip flute path; check coolant flow rate at the drill tip with a flow meter

I have also seen intermittent faults trace back to coolant concentration drifting as water evaporates over a weekend, a worn collet that grabs tight or loose depending on temperature, and even a chip conveyor that jammed only when a specific part geometry produced long stringy chips.

If you have ruled out the obvious suspects and are still chasing ghosts, a structured root cause analysis will help you organize what you know and find what you are missing.

Ruling Out Variables One at a Time

The temptation with intermittent problems is to change everything at once and hope. I have done that. It does not work. You end up with three changes in the window and no idea which one actually mattered.

My rule now is one variable per production run. If I suspect coolant temperature, I run the chiller manually at its lowest setpoint for an entire shift and see whether the problem disappears. If it does, I have my answer. If it does not, I can cross coolant off the list and move to the next candidate without ambiguity.

There is a nuance worth mentioning: intermittent problems sometimes have a trigger that is not a single variable but a combination. Coolant temperature plus a specific material batch plus a worn guide bushing may add up to a failure where any two of those alone would pass. These multi-factor cases are rare, but when you run into one, you will only find it by holding every variable you can control constant while intentionally shifting one at a time.

Building a Run Chart

A run chart is the single most useful tool I have for intermittent problems. It takes the log data and turns it into a picture that my brain can recognize instantly.

I plot the variable I suspect (coolant temperature, spindle load, bore diameter) on the vertical axis and part number or time on the horizontal axis. Then I mark every occurrence of the problem with a red dot or a different symbol. What I am looking for is a clear zone: above a certain coolant temperature the red dots cluster; below it they do not. That temperature is my threshold.

The real power of a run chart shows up when the threshold is not obvious. I had a case where the run chart revealed that every bad part occurred when the spindle load drifted above 65% and the coolant return temperature was above 28 °C at the same time. Neither condition alone caused trouble. The chart let me see the interaction that my log table could not make visible.

I use graph paper and a marker for quick shop-floor charts, but a spreadsheet works just as well. The important thing is to start the chart before you start changing things. Baseline data is irreplaceable.

Key Takeaways

  • Intermittent problems demand a different mindset from continuous ones. You are hunting a drifting threshold, not a single fault.
  • Keep a written log of every run alongside the problem. Capture coolant temperature, material identifiers, and anything else that changes from cycle to cycle.
  • Intermittent causes almost always involve a slowly fluctuating variable: coolant temperature, material hardness, bushing wear, or thermal growth of the machine.
  • Change one variable at a time per production run. Multi-variable changes make it impossible to isolate the real cause.
  • A run chart turns your log data into a visual tool that reveals thresholds and interactions you would miss in a table.
  • When you are stuck, go back to the data collection plan and the root cause analysis framework. The answer is in the data if you have collected the right things.