Freesteel Blog » Toolholder frustrum consolidation shape

Toolholder frustrum consolidation shape

Thursday, October 30th, 2008 at 11:41 am Written by:

It’s taken nearly a week and 400 lines of C++ code to complete the algorithm shown in the above picture, where a series of trapeziums, representing the conical sections of a tool holder, are merged into one continuous monotonic (in radius distance from the axis) piecewise linear curve.

We get these kinds of non-joined up segments when thickness is applied to the toolholder shape and all the previously consistent sections start to overlap in various ways depending on how much material you’re adding. It’s important to have a consistent contour to work with because you can code things much faster than checking the collisions of all the independent segments individually. For example, when you lower the cutter down in Z onto a point, the distance between the point and the axis tells you the unique conical segment that it will collide with. No need to check any others.

You notice in the drawing the big triangle contributes three individual segments to the final red line. This aligned envelope finding algorithm — pain though it is — is about a 100 times easier than the polygon intersecting algorithm which you have to implement if you want to find the offset contour from an arbitrarily shaped pocket slice. That’s an algorithm many CAD programmers have foolishly tackled, not having the wit to recognize the extreme difficulty of it. In fact, if I was giving CAD developers interviews for my job I’d ask them to tell about how they would approach the problem of finding the offset of a polygon, and if they showed any confidence of being able to do it, they’d fail the shortlist. Only by suspecting that you’ll have a hard time doing it by brute force (which results in a debugging project for the next 20 years) are you likely to hunt for and find out about the real solution, which involves Voronoi diagrams of lines (not the simpler one of just points).

For some reason I’ve stupidly implemented it in C++ rather than Python, probably because I needed to use my Along(lam, a, b) function and other little quirks in my small functions library. This means that we need to provide accessor functions to get the results back out of the C++ objects and into the Python, which is the interface to the graphical visualization tools. Maybe when I’m feeling I’ve got the time I’ll convert it from one language to the other (or someone else can volunteer if they want to — I’ll give you the code). Like I said, I made the wrong choice. I’ve been having a heavy cold all week, which may have clouded my judgment.


  • 1. Neel replies at 30th October 2008, 6:29 pm :

    why dont just find the curve of the tool & tool holder before the thickness is applied and then offset this curve by thickness value?

  • 2. Julian replies at 4th November 2008, 11:24 am :

    Because I don’t have that general-purpose function, and I’m never going to write it.

    There are also much more complex toolholder shape transformation regimes which are easy to compute on the wedge components, but not on the compound shape. Such as one where you stand the tool on its tip and pivot by 5 degrees in all directions, to get a shape that’s much more fattened at the top than it is at the bottom.

Leave a comment

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