Random tolerance rant

Thursday, January 11th, 2007 at 1:56 pm

The New Year blues were wearing off just in time for my laptop computer to crack up (the problem seems localized to the network circuitry). This delayed me getting to grips with this delightful adaptive roughing bug I discovered while investigating a completely different bug. How it looked at first is in the right; how it ought to be is on the left.

There is always a trade-off between speed and quality. Normally you control this with the tolerance value, which controls the sample rate of whatever is going on in your algorithm.

In any one machining algorithm, there can be dozens of distinct tolerance values to set the precision of the triangulations, the precision of the zslice contours, the rate at which the cutter is sampled, the tolerance at which the toolpaths are thinned (the process of converting nearly colinear sequences points into a single straight line), and so on.

The user isn’t going to want to set all of these independently, so we usually give them a control tolerance, and then set all the alternative tolerances proportionately.

For example, if the user tolerance is u, we might set the triangulation tolerance to u/3 and the machining tolerance to 2u/3.

The triangulation tolerance conventionally limits the deflection between each triangle in the model and the designed parametric surface. As it gets tighter (smaller) you get smaller triangles and more of them.

The machining tolerance conventionally limits the amount that the cutter will gouge the model. Since it’s too hard to simulate the swept volume of the tool against the triangulated surface, it’s sampled at descrete positions along the toolpath. As the samples get close together, the quantity of the material which can be over-cut from the model decreases. (See this post for a diagram).

The sum of these two tolerances gives the user tolerance; the error is shared out by the two stages in the process. There’s a trade-off as to what proportions of the user tolerance to share between the triangulation and machining tolerances. If the triangulation tolerance portion gets smaller (and its tolerance gets tighter) you get more triangles, which slows down the speed at which you can calculate a cutter position. But since the machining tolerance portion gets larger, the cutter location sample rate gets wider and you need less of them.

Because of this trade-off, no one bothers to look at what would be the optimum proportion to share out these tolerances. There’s probably a minimum, but it may be long and flat, so any value between 0.1 and 0.9 will probably do. Programmers generally pick a number without too much thought as they’re writing the code, and no one gets around to looking at it again for decades, if ever. There are almost certainly some stunning improvements in performance to be had in some CADCAM routines just by reviewing these numbers in case someone has been unlucky with their guesswork.

There’s also an art to it. Just because you set a tolerance value, doesn’t mean that the result is going to reach that level of inaccuracy. For machining, you normally sample at the rate suggested by the tolerance value, but also subsample quite a bit when there’s a corner, which is where the tool is most likely to have gouged. This means that the machining tolerance is usually much much better than the value put in, but you can’t rule out the possibility that there is some tiny feature on an otherwise flat model which the sample rate simply misses.

The triangulation tolerance, on the other hand, behaves quite differently. Since this is the surface that is being used to find the cutter locations, the tolerance limits set on it will be used. The worst accuracy generally occurs in the middle of the triangles, and it doesn’t take bad luck to hit those locations routinely.

That’s why, given the choice, it’s better to have a tighter triangulation tolerance and loosen off the machining tolerance. Unfortunately there’s a tendency to economize on the triangulor in many systems, and that’s wrong the wrong compromise.

So, back to the adaptive clearing bug. There’s a sample rate for the cutter engagement modelling here too, which I set at 3 times the machining tolerance. Don’t know why; I just did. Since the tool is always bound by the contour, nothing it can do will ever gouge the model, making it hard to relate its meaning to what users normally refer to as tolerance. They just want something to work.

What made it interesting was that when I started tinkering with the values, like setting the sample rate to 2.5 times the machining tolerance, the problem disappeared suddenly, not gradually. It was as if some nasty resonance was getting in there from the sample rate and the cutter engagement, making the paths get worse and worse until it showed up to the naked eye.

I could have quickly fixed the bug this way, by adjusting the sample rate, and slowed the whole system down slightly, and not cared if this resonance condition could re-emerge in some other case I no one yet knew about. However, this is my code and I intend to still be maintaining it in 5 years time, which means it really matters to me if there’s thousands of people using this software then and I’m having to work night and day to stay on top of a vast list of creaky problems.

That’s code rot. Numerous little quick fixes keep coming back to haunt you, until it’s like a over-patched roof with nothing good left to nail things to, and it has to be thoroughly replaced. You don’t want to do this with software; it’s so difficult to see how bad things are getting that what normally happens is someone else makes a totally independent set of software from scratch and it’s better than yours.

Anyway, the correct fix was easy. I added in another couple of tolerance values. When the toolpath changes direction by by more than a certain amount (eg 30 degrees — a number I picked out of a hat), the minimum sample distance is allowed to get smaller by a factor of 3.