## Pencil overthickness

Tuesday, September 11th, 2007 at 5:20 pm

How do I get any work done? I don’t. I’ve been getting mightily pissed off with it, which is why everything is a distraction. If it wasn’t for this UN website, I’d be fixing every hole in every sock in my drawer just to avoid doing what I’m supposed. It’s like getting programmers’ block.

Things have settled down a bit. I have a large function to write to do with testing cutter interference with triangles, but it’s mostly a ten finger exercise. The structure of it is already given, so all I have to do is write the routines which tell whether a given edge intersects with a given cutter position without calculating how high in Z that cutter needs to be lifted in order to no longer intersect with it. The formulae are all different, but much simpler; all I have to do is fill in the blanks. This function is used in some of the linking routines, although obviously the lift-cutter function will give the answer just as well (the cutter intersects if and only if it gets lifted), although a little slower. However, having the lift-cutter value when it does intersect is useful for creating the shortest link paths.

That does remind me that someone will maybe want to know which side did the interaction so as to move the cutter sideways in the opposite direction by the right amount. But this won’t be found in the fast routine, because the function will quit as soon as anything is found in the way. Although maybe this doesn’t do a lot of good since if you do quit early after having found a collision, you now don’t have a valid cutter location, so you will need to know where to look next. Encouraging the scatter-gunning of a lot of points doesn’t seem to enable the right answer.

I don’t write the linking algorithms myself; it’s a fidgety job left for the boys at Cimco. I expect to see the horror of someone using this fast test-for-intersection routine to binary-search for cutter locations near the place they want because it’s too hard to find the right function.

A follow-up function will do the same for sweep volumes of the cutter so that you can tell immediately if a long segment of linking path does not collide with anything.

None of this actually achieves any new functionality; it’s all for speed and efficiency.

Pencil overthickness This was an idea I came up with years ago while writing Machining Strategist/Depocam. Could have been around 1997. One would have to review the old instruction manuals to pinpoint the date. To the best of my knowledge, I am the originator of this strategy. Although there is so little access by the programmers to the features of someone else’s CAM system that this feature might be rife everywhere, and each team has invented it independently.

As it doesn’t say in wikipedia yet, pencil milling is the the toolpath you get by connecting up all the cutter locations where the tool is in contact with the part twice. These are normally along grooves where there is a distinct corner or a concave surface whose radius is less than that of the cutter. It has been conventionally used to leave smooth fillets along these internal corners with by following them with a ball-nosed cutter of the appropriate size so you don’t need to program the fillets into the model. What you design in the CAD is not the same as what you eventually cut. It’s simplified. Your biscuit mould might be made with sheet metal sharp corners, but the cooked biscuits are attractively rounded at the edges due to the process of baking.

Then along comes the modern day CAD systems with all their fancy-shmancy reliable filleting routines, and people start designing exactly what they want cut, including all those rounded grooves. Suddenly when you test the tool against them there are no longer any clear double contact point locations. They’ve added smooth ramps to the pavement curbs so you don’t notice the bump when your bike rolls off into the road.

The answer is to use overthickness. If you applied thickness to the cutters (add a value to all dimensions of the cutter to make it bigger), you could recover the pencil passes that had been obliterated by the presence of these stupid fillets that were set to the radius of the tool you wanted to cut with. Then if you projected these passes for the bigger cutter back to the surface, you’d get a result that was consistent with what the user wanted.

And therein lies the problem. Since I haven’t got a “project this toolshape in a slantwise direction to hit the surface” function, I’m having to do it by dropping the smaller cutter somewhere in between the contact points along the vertical axis. The results are terrible in this example no matter what I do. I’ve tried all variations of dropping the cutter at points that are not half-way between, at points that lie along the curve on the tooltip joining the two contact points, but nothing works.

I don’t think it worked consistently in Depocam either, but those were the old days before models started getting ridiculously wobbly and complicated, and features like this were known as advanced, so you were quite pleased if they worked at all for what you were doing.

So, I have to give up on this. The ultimate answer probably has to be these five-axis features, where the cutter is not lowered into contact along its axis, but is brought slantwise along arbitrary vectors. Then I will position the small cutter at the centre of the thickened cutter and project it at the fillet surface along a smoothly varying vector.

Which brings me back to the beginning. This will be a season of heavy finger-exercises slamming out the calculations for all these different geometric configurations. That and the other major complaint about the speed of the constant scallop routine under some circumstances has to be addressed. It’s all a nuisance.

Roll on those multicore processors now already. I’ve a lot of ideas for parallelizing the computations, and this will be a lot more interesting and fruitful in the long run than shuffling around stupid instruction sets or tuning parameters that no one is interested in.