Freesteel Blog » Pencil overthickness where there are pencil passes

Pencil overthickness where there are pencil passes

Monday, October 11th, 2010 at 10:51 am Written by:

It’s been a while since I’ve done any machining work. This bug has been pressing for a while, owing to the incompleteness of the pencil overthickness algorithm.

In theory pencil overthickness is straightforward. You have a fillet that has a radius bigger than the cutter, but you want the tool to run along the fillet, so you thicken the tool by several millimetres so it is bigger than the fillet and forms a pencil path (ie a linear locus of of cutter locations with two points of contact with the model), and then project that toolpath into the fillet at the half-way angle.

This is all very well, unless the there should actually be a pencil path for the smaller cutter, when the projection will miss the pencil pass and you’ll just get passes that are a little offset of where you would prefer them to be.

This is undesirable. You want to make it seem that the pencil overthickness allows it to pick up more passes than otherwise, not produce a completely different path. Otherwise to get a good result users would have to know the fillet radii in different parts of their job and possibly draw boundaries around them in order to set the appropriate overthicknesses to make it right.

So I have a special case. If, on projection, there appears to be a pencil pass along the fillet, then we project to it.

Now we have a new special special case where the pencil pass for the small cutter goes only part way along the fillet.

This is quite a complex fillet shape to consider. Not only is the radius of the fillet changing (from smaller to larger than the radius of the cutter), but the double point of contact is changing from one side to the other as it rolls off the shelf.

After a few days hacking through loads of unfamiliar code, and realizing that the one big difference between Python and C++ is the lack of the std::list<> object and all its associated habits of iteration, I have a feature that can extract both types of path from the channel and not have them overlap.

Okay, so there is no good transition from one to another, but that’s a minor detail. Every feature you put in like this has so many associated parameters to deal with new thresholds. What’s going to happen when you are on the boundary value and you have 1mm of real pencil pass, followed by 1mm of projected pencil pencil pass alternating in fragments probably as a result of the facets of the triangles? What distance do we join across? I don’t want to go anywhere near any transition algorithm, as it would be difficult to design and test, and the examples (like this one) are exceptionally rare.

Here’s a picture of some of the internal projection passes:

You can see the lower white path (at the halfway point on the larger fillet) continuing up past where the bitangency points start.

I’ve tried steering it more into the tight cornered groove, but it can get wobbly in some examples where the curve is smoother from one end of the perpendicular pass to the other, so that the corner is ill-defined.

The code runs kind of slowly with such a huge amount of sampling along these perpendicular passes, but at this point any acceptable result is good. Speed and efficiency is not the biggest concern, and will be got by fiddling with the parameters controlling the sampling along these perpendicular passes (which I am sure are very over-sampled). Unfortunately we don’t have a system to allow meddling with it systematically yet. This would be one that compared output passes for differences and a set of scripts that reran all the benchmarks and bug examples over and over again with slightly differing values to find out where the cutoffs are.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>