The Day The Cone Went Quiet (And My Boss Went Loud)
In early 2023, I got a panicked call from a site in Nevada. Their Metso HP800 cone crusher, a machine I'd helped spec and install, was drawing low power. The throughput was down, the product was getting coarser, and the automation—a brand new Metso IC70C—kept flashing a 'Setting Limit' alarm.
The crew chief was convinced it was a software bug. "This new automation crap," he grumbled. "Just needs a reboot." I'd heard that before. I personally made that mistake in 2021, costing about $3,200 in wasted downtime and a very awkward call to my boss. So I knew better than to reboot first.
That $3,200 mistake (and the 1-week delay it caused) is why I now maintain our team's pre-call checklist. Here is what I found when I stopped blaming the computer and started looking at the actual problem.
The Surface Problem: What Everyone Sees
Everyone sees the same thing: the crusher isn't making spec. The symptoms are almost always:
- Low power draw at the motor. The crusher isn't working hard enough.
- Reduced throughput. Fewer tons per hour coming out.
- Coarser product. More oversize material making it past the closed side setting (CSS).
- Erratic automation. The IC70C making constant adjustments, throwing alarms, or refusing to set a stable CSS.
Everyone's first instinct is to blame the most expensive or complex variable. In a modern cone crusher, that's the automation. It's the 'brain,' so it must be the one having a stroke, right?
The Real Issue: It's Almost Never The Automation (But It's Almost Always Related)
What most people don't realize is that the IC70C automation system is incredibly robust. It's not a buggy piece of software. It's a very accurate doctor giving you a diagnosis you don't want to hear. When it says "Setting Limit" or "Crusher Overload," it is measuring a physical reality. The issue is that most operators don't speak the language.
The assumption is that the automation is causing the poor performance. Actually, the poor performance is causing the automation to behave oddly. The relationship runs the other way. The IC70C is the messenger, and people keep shooting it.
Here are the three hidden causes I have documented, costing myself and our clients a small fortune over the last five years.
1. The Parts (The 'Metso Compatible' Trap)
I saved a client $400 on a set of bowl liners once by using a budget 'replacement' part. The compatibility chart said they were a direct fit. The price was great. The salesman was smooth.
Three days after installation, the crusher started surging. The IC70C was constantly pulling feed back. The operator said the automation was broken. I knew better (ugh). We pulled the liners, and the profile was slightly off. They literally didn't fit the crushing chamber geometry designed for the machine. The result: $400 saved, $4,500 spent on new OEM liners (thankfully), plus a day of downtime.
People think that 'replacement parts' are 'Metso parts.' The reality is that the metallurgy, the profile, and the exact weight of an OEM liner are part of the system design. The IC70C is tuned to a specific machine. When you change the machine's geometry with a non-OEM part, the automation doesn't know how to react. It just sees a problem.
2. The Data (The Crewe Tractor Analogy)
This one is a bit weird, but bear with me.
I work with a guy who restores old tractors. He told me about a Crewe tractor he was fixing. The engine was fine, but the hydraulics were sluggish. He tore the whole system apart looking for a bad pump. It turned out the problem wasn't the pump. It was a tiny, almost invisible bit of sludge in the return line filter. The filter was fine with clean fluid, but it couldn't handle the normal wear debris from the system. The pump was perfect. The data (low pressure) said 'pump failure.' The real problem was 'filter restriction.'
Now replace 'hydraulic pump' with 'cone crusher' and 'sludge' with 'feed material variability.'
Your IC70C collects a ton of data: power draw, hydraulic pressure, CSS setting, tramp release count. People look at a high tramp release count and say "the relief valve is faulty." But what if the high count is because the feed material has more fines than usual? The automation can't tell if a spike is a steel tramp or a clay ball. It just sees a pressure spike.
The most common mistake I see is people trying to fix the data (the symptom) instead of the physical reality (the cause). The automation is happy if the physics is happy. If the physics isn't happy, the data looks bad.
3. The Wrong Tool (A Crane Fly vs. A Mosquito)
This is my favorite analogy.
A crane fly looks like an enormous mosquito. If you see one in your house, you might panic. But crane flies are harmless. They are built for different things than mosquitoes. A mosquito has a fine, precise proboscis for blood. A crane fly is all about flying and reproducing. They look similar, but the application is entirely different.
I see the same thing with crusher automation setups. A customer will buy an IC70C for a primary crusher and expect it to act like the automation on their secondary machine. It will do a job, but it's the wrong tool. The IC70C is a brilliant instrument for optimizing a cone crusher. But if you try to use it as a primary feed controller or a plant optimizer, it's like using a scalpel to chop down a tree. It's not designed for that.
The real issue is often that the operator has tasked the crusher (and its automation) with a job that the rest of the circuit isn't supporting. If the screen before the crusher is blind, the crusher gets all the fines. The automation will try to compensate, but it will hit limits. The automation isn't broken. The physics are simply unacceptable.
The Cost of Ignoring the Root Cause
In my experience, every one of these issues leads to the same pattern of cost:
- Direct waste: The $4,500 for new OEM parts after the cheap ones failed. The cost of a service call to 'fix' a non-existent software bug.
- Production delay: A 1-week schedule slip while we waited for the right parts. That delay cost more than the parts.
- Erosion of trust: The operator stops trusting the automation. They override the IC70C and run the machine manually, negating the entire investment and opening the door to human error and damage.
Missing the fact that the 'cheap' liner was the problem resulted in a 3-day production delay, not the 4 hours we planned. The numbers said one thing. My gut said to check the liners. I listened to the numbers and paid for it.
So, What Should You Do? (The Short Version)
If your Metso cone crusher (MX, GP, HP – doesn't matter) is running poorly, don't touch the automation until you've checked these three things in this order:
- Check the parts. Are they genuine? Have they been replaced recently with a non-OEM 'equivalent'? If in doubt, get the part number and call your dealer. (We caught 47 potential errors using this checklist in the past 18 months).
- Check the physics. What is the actual feed material? Is it wet? Dry? Has the gradation changed? A change in feed is the #1 cause of 'automation failure.' The IC70C is just telling you about it.
- Check your expectations. Are you using the right tool for the job? The IC70C is for managing the crusher chamber, not managing the whole plant.
The vendor who tells you the automation is fine and to check the circuit (like a water pump delivering consistent feed, or the screen deck before it) is the one you can trust. The one who wants to sell you an automation upgrade for a problem a crane fly would see...don't buy it.
My goal is to save you from my $3,200 mistake. Start with the simple stuff. The IC70C is probably right. You just have to learn what it's telling you.