## Side contact normals

Tuesday, June 5th, 2007 at 2:47 pm

Trivial bug discovered only by visualization. This one’s been in there for several years.

When making waterline (const-z) passes with a tool that is larger than the smallest fillet radius in the model, you get sharp corners. These need to be rounded off for high speed machining. I do this by slicing with a tool whose radius us increased by c, and then offsetting the resulting areas outwards by c to get the contours in the place where we want, but with the corners replaced by arcs of radius c.

The advantage of doing it this way, as opposed to geometrically detecting the corners and fitting arcs to them, is that you don’t get under-cuts because the calculation is always consistent. In 3-axis machining you don’t ever want the area of a lower level to stray outside that defined by an upper level or you risk a tool-holder collision.

A classical error is for the upper level to be a rectangle of, say 100mm on the side, and the lower level to be a truncated corner, a tiny triangle of 2mm on the sides. If you’re running very fast you might add corner rounding of 5mm onto your rectangle. The largest corner radius you can fit on the triangle is about 1mm, so that’s all it gets. The resulting lopsided triangular circle will be totally outside the rounded rectangle.

This is an extreme case. The risk of incompatibility is high when a complex algorithm is independently applied to adjacent paths. The passes A and B have the containment relation A << B. If corner_round() represents the corner rounding process — a deeply complex algorithm — then it’s not always true that corner_round(A) << corner_round(B).

In Machining Strategist they had to write an even more complex function to intersect the areas corner_round(A) and corner_round(B) to deal with this under-cut problem.

I don’t have time for that, so I re-apply a variant of the z-slicing algorithm to make the offsets. This offset() algorithm is far simpler than corner_round(), so it is always true that offset(A) << offset(B).

And it works, so long as you don’t calculate the perpendiculars that drive the subdividing condition wrongly. Here I managed to negate the y-coordinates when the offset came from a point. This manifested itself when the contour had a 90 degree corner on it oriented to go from half-past one o’clock to 4:30 causing an erroneous lack of subdividing before I fixed it.

### 1 Comment

• 1. Anders replies at 5th June 2007, 3:16 pm :

Hi Julian,

It seems that for surface machining there are two ‘camps’, the academic one that prefers complex math based surface offsets, and the commercial camp that does this using triangulated surfaces and ‘drop cutter’ algorithms.

Now that you mentioned 2D curve offsetting in this post, I’m wondering if there is a similar situation for calculating offset curves?

In principle it’s not difficult to calculate exact offsets for lines and circles (which makes sense since all machine controls have G1,2,3 moves), but the problem is joining all the resulting segments into the proper offset curve.

So I guess I am asking if you also use a more pragmatic and robust 2D curve offset algorithm? and would you care explaining how it works?

keep up the nice blog!,

Anders