RPM, Chipload, and Tool Deflection: A Surprising Relationship

Jul 26, 2011 // by Bob Warfield // Blog, Software, Techniques // No Comments

In Physics, we have three ways of finding precise answers to questions:

1. We can conduct an experiment and directly measure the result.

2. If we have the math equations to directly deduce the answer, we can calculate it.

3. We can use computers to simulate the physical system and derive an answer by conducting virtual experiments with the simulator.

G-Wizard Calculator incorporates elements of all three approaches. It contains a large number of math equations which it will happily plug values into in order to give you back an answer. It is able to combine those equations to produce simulations, which is really what the feeds and speeds calculator is–a feeds and speeds simulator. Lastly, it is regularly calibrated using real physical data. For example, whenever I read a thread where someone asks the best feeds and speeds for some tooling and material, and others chime in with what has worked in their experience, I always plug the numbers through G-Wizard to make sure it is calibrated to agree with the experience. Over time it reached a stage where for most materials and tooling it’s pretty darned close to the voice of experience, which makes it a useful tool indeed.

I mention all this because I was recently confronted with a conundrum where the simulation in GWC was producing an answer I just didn’t believe. I was asked in our User Club Forums to develop a feature for the Cut Optimizer that would allow it to vary the spindle rpm to reduce tool deflection within allowable limits. Up to this point, it has been able to vary cut width, cut depth, or feedrate, but not rpm. It seemed like a great idea so I launched into the work with gusto. Coding didn’t take very long, and that led to testing. For some reason, the Cut Optimizer could not optimize for rpm–no matter what rpm it tried, the tool deflection was about the same.

“Obviously a bug,” says I, and I set about trying to track it down. Eventually I got down to the formula that calculates the force applied to the endmill and saw that changing rpm was not changing this force. When you’re down to just one formula, there isn’t much room for bugs to hide, and I soon tired of trying to find one. As Sherlock Holmes remarked, “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.” So I went looking at other calculators capable of determining the force on the cutter and sure enough, the rule held true:

So long as chipload remains the same, changing rpm does not affect the force on the cutter, and hence does not affect the tool deflection.

But I was still not satisfied because the problem with simulations is they provide no underlying intuition for why their answer is correct. Normally, we just want the answer and don’t care about the intuition, but when the answer is a surprise, I want some intuition to learn from too!

So, I wrote down all the equations involved and started manipulating them with algebra. Eventually, it dawned at the formula level–the rpm’s were cancelling out with one in the numerator and another in the denominator so they couldn’t affect the math. I still wasn’t satisfied until this morning, when I finally hit on a more geometric intuition for what’s happening.

What is Chipload?

To understand this intuition, we need to think about what Chipload really is. Chipload is measured as inches per tooth or mm per tooth depending on your system. It is a way of characterizing the chip that each individual flute of the cut slices off the workpiece. We may want to make cuts that create a chipload of 0.004″, for example. Assuming we have successfully achieved that chipload, if we collect some chips and measure them, we should find that their thickness is literally 0.004″. Peeling up that chip produces the bending force that causes tool deflection. Think of you cutter as a succession of chisels, each peeling up an identical sized chip. Whether you have 1 flute or 10, each is a chisel that is rhytmically peeling up those chips.

Now whether you have a 1 flute flycutter running at one particular rpm and feedrate, or a 10 flute face mill running at another rpm and feedrate, so long as the rpm and feedrate are properly orchestrated, we wind up with the same chipload. Therein lies the problem with manipulating rpm to reduce tool deflection:

If we change the rpm, but maintain the same chipload, we force feedrate to change in a way that creates exactly the same force at any rpm we choose.

That’s because our little chisels are pulling up the same sized chips, just at different rates. Each chip pulled up deflects the tool, then the deflection eases as we finish the chip, then we start deflecting again with the next chip. Over and over it goes, but the absolute amount of deflection is really just based on the deflection of one single chip. Put another way, keeping the chipload constant will force the feedrate to change just enough for any given rpm that the force is matched.

Does this mean rpm doesn’t matter? Of course not. RPM doesn’t matter to tool deflection (so long as we keep chipload constant), but it matters a lot for tool life, surface finish, and chatter. That rhythmic deflection is precisely what excites chatter, for example. It also directly affects Material Removal Rates. Just not Tool Deflection.

So, in the end, no new feature for cut optimizer. Darn! Seemed like a good idea at the time.