FreeCAD Path Workbench – Big Vision and Baby Steps.

For the last few months I’ve been helping out with a side project to write a CAM workbench for FreeCAD.  Being a not-very-good programmer, I’ve focused on cheer-leading, testing, and trying to stay out of the way.  The project has come a long way, but it will still be a long time before the average user sees it.  Still, it’s a good time to start talking about the workbench, setting expectations, and encouraging folks to take a look.

Big Vision:

Don’t we already have open-source CAM tools? Why do we need another one?

A quick Google search or browsing through the LinuxCNC wiki would make you think the field is already crowded with alternatives.  If you’ve actually tried to find a functional solution though, you probably already know the answer.  Most of the projects out there are stale, offer limited utility, or are very specialized.  A lot of them are completely dead. To be fair, some of the projects like BlenderCAM, HeeksCNC, and the Inkscape plugin gcodetools offer decent hobby-level functionality but there’s nothing that competes with the commercial alternatives.

To be competitive, an open-source alternative really only needs two things (and time):

First, the application has to be user friendly:

• Cross Platform
• Integrated with CAD
• Reasonably Intuitive
• Fast

Cross Platform means the application meets the user half way.  Learning the application means the user will have to understand new concepts, watch tutorials, read manuals, and suffer through bugs.  Asking them to change operating systems or compile from source is unreasonable.  Integration with CAD doesn’t mean the user should change his primary design tool but the line between CAD and CAM gets kinda fuzzy in practice.  Visualizing your tool path as it relates to your base geometry and making minor tweaks to the design to get a usable path are common.  Switching tools for minor adjustments is annoying and leads to errors.

The application doesn’t have to be a marvel of form and function but it needs to have a reasonable UI.  By this I mean that it should work for a hobbyist who needs to set up a simple CNC router job but provide capabilities for an experienced machinist to set up more complex jobs as well.  (multiple fixtures, tool tables, and selection planes).  It should let users customize their configuration so the output is predictable and works with their machines.

And, of course, it’s got to be fast.  ’nuff said.

Second, the project has to appeal to the developers:

• Reasonably easy to learn
• Great community
• Clear license policy

Plenty of digital ink has been spilled discussing what it takes to make a great open source project so I’m only talking about those things that I’ve personally seen kill open-source CAM projects.

The number of people in the world that have both programming skills and machine tools is pretty limited.  For open source CAM to succeed, the developers who show up need to be able to get into the project easily and become productive.  A great open source CAM project would have a great architecture, robust community, thorough documentation and large user base.  It should be easy for a new developer to understand the landscape and figure out how to improve application -even a little bit- and then get their improvements adopted by the project.

I’m not sure anybody including lawyers actually like dealing with licenses but they’re a reality we have to live with.  If the license landscape isn’t unambiguous, packaging and distribution of the application is a non-starter.  If the license doesn’t protect the developer contributions and make it easy to distribute, why bother?

Time

The things I’ve listed aren’t rocket science and they don’t, by themselves, make a great application.  But together they create an environment in which a great application can mature.  Obviously I’m writing this because I think the FreeCAD Path project has this particular mix.

So where is the project now?

Rather than trying to provide all the functionality of a mature CAM application, Path will initially provide only the basics.  In fact, the real focus will be on the underlying infrastructure.

Like other workbenches in FreeCAD, the low level stuff is programmed in C++ and the high level, user-facing, functionality is written in Python.   The low-level stuff includes the data structures to represent a single move (command), a group of moves (path) and other structures for organizing projects.  It handles representing those things on the screen and provides the interfaces to Python so they can be manipulated by the GUI and macros.

An import framework is provided so path information created externally can be loaded and rendered within FreeCAD.  Likewise and export framework exists to get path data out in a usable form.

If importing and exporting were only provided through the compiled C++ application code, it would mean that FreeCAD’s ability to read and write gcode would be fixed and difficult to adapt.  So the import/export framework is exposed through a set of  pre_ and post_ scripts written in Python.  This means FreeCAD can play nice with all kinds of other applications.  If you already have a program that generates gcode, you can import the code into FreeCAD.  If your machine needs gcode in a unique dialect or modified some other way, you can tweak the export post_ script to get exactly the what you need.

This is pretty handy but most users will want to create gcode directly from the things they design in FreeCAD and this is where things get interesting.  Experienced CAM users opening the workbench for the first time will be asking questions like, “How do I create a profile or pocket a feature?”   CAM operations like this will be implemented as a Path-Python-Feature (PPF).  A PPF is a python script that uses the FreeCAD API to generate the path data.  Almost everything you will see in the workbench GUI represents a PPF.  PPFs can have have icons and dialogs and integrate seamlessly into the workbench GUI and power users can study and extend their functionality.

Now is the time to set expectations.  The initial set of PPFs will be limited.  Users just looking for a functional CAM system might be disappointed.  There will be pocketing, profiling, and drilling operations, but they will have plenty of bugs and missing features.  Other kinds of operations, like 3D surfacing, will be missing altogether.

CAM users will also be looking for tools to organize operations into a complete project — Sequencing, tool management,  part nesting, etc.  Early users of Path will see some of this but it too will be buggy and incomplete.  Users should expect things to change a lot in the near future.

Because all of the PPFs,  project structure, and pre/post processing is written in Python its pretty easy to experiment with and improve.  No doubt, an active community will mature the operations quickly and add new ones as well.

Once Path is merged into the Master branch of the FreeCAD development repository, it will still be quite a while before end-users see it.  Users running the development version will see it, of course, but it might be a year or more before Path makes its way into a stable version.  By then, the functionality should be more mature and usable for real CNC projects.