The Hell Ya Beller Fun with hot, pointy, sharp, and caustic stuff.


Understanding Tool Path Generation in HeeksCNC

When I first started using HeeksCNC I was totally confused.  It seemed overly complex.  When I finally understood it, I realized what a great model it is.  I still won't claim to be an expert but from my perspective it meets three really big objectives.  One of these is compromised in every other solution I've seen:

1) It keeps the computationally intensive algorithms in C++ where they run fast.   Other systems that are flexible and customizable are written in interpreted languages and that means they're slow for computationally intensive tasks.  Generating a complex path can tax a processor and really needs to be fast.

2) It provides a scriptable interface in a friendly language (Python).  No matter how good the developer was, there's no way he can anticipate every need.  That's why we like applications like blender, inkscape, gimp, and FreeCAD.  These apps assume that the user may want to extend the application.  Making the tool path generation accessible through a scripting language unleashes a lot of power.

3) It allows customization for the machine specific output without recompiling.  This is the Post-processor.  Not all machines are created equal.  Different capabilities and different controllers mean the final output must be tailored.

Dan Falck did a great write-up of how Python is used in HeeksCNC to generate tool paths using the C++ libraries.  I hope a future CAM workbench for FreeCAD has a structure like this.

Comments (1) Trackbacks (0)
  1. This is good news! I suggest to keep the workbench minimal and simple at first.
    I see about three interfaces or APIs that need to defined.
    1 How is geometry pushed from FreeCAD into a CAM-plugin. I suggest simple primitives: point, line, circular-arc, triangle (for surfaces). Not much more, if anything should be required.
    2 How are toolpaths communicated back from the plugin to FreeCAD. This is some high-level version of g-code, i.e. rapids, and g1/2/3 moves. Once the toolpath is a freecad geometry object it can be viewed, shown/hidden etc. and eventually run through the post-processor to produce machine-specific g-code.
    3 How does the plugin define its own GUI and let FreeCAD know about its existence. Each plugin/operation could have its own toolbar-icon, requirements for input geometry, tool (from a tool library, that can come later), settings (i.e. step-over, cutting-depth etc).

    Drop me an email if/when something gets going. I will definitely try to see what can be done with openvoronoi and opencamlib if someone can give a bit of help on the freecad front.

Leave a comment

No trackbacks yet.