Meshmill: open source 3D CAM

Tue 3 May 2022
Tagged: software, cnc

For the last couple of weeks I've been working on Meshmill. It's a new 3D CAM program for Linux.

If you run Linux (on x86_64) and want to try it out, you can download the AppImage from the Github repository.

If you try it out (successfully or otherwise!) please let me know how you get on, what you struggled with, etc. And I'd love to see pictures of your parts :).

I have filmed an introductory video showing how to use it to make a part:

What is 3D CAM?

You can machine a lot of parts by machining features at different heights in flat planes. This is called "2.5D" machining, because although the produced parts are 3-dimensional, all of the tool movements are only in the XY plane, with the Z axis only moving to get into position before the start of each level. You can only make surfaces that are horizontal or vertical.

(From Welsoft)

Most of the parts I make on my CNC machine are made with 2.5D toolpaths generated by FreeCAD.

To make parts that have angled or curved surfaces, you need to move the tool in the Z axis at the same time as the X or Y axis. This is "3D" machining, and this is what Meshmill is designed for.

(From Welsoft)

FreeCAD has some buttons that are supposed to be able to generate 3D toolpaths, but I've never been able to get them to work. PyCAM makes 3D toolpaths but I always ran into Python errors when trying to run it. BlenderCAM is supposed to be good, but I only found out it exists after I started working on Meshmill, and although I have used Blender on occasion, I find it too complicated.

How does it work?

In 2020 I wrote a tool called Pngcam that takes a heightmap as input and produces G-code as output. It also has another tool that takes an STL model as input and produces a heightmap as output, so that they can be used together to make G-code from an STL model. Pngcam is a 3D CAM program, but it is inconvenient to use because it is operated from the command line.

Meshmill is an Electron application providing a GUI frontend to Pngcam.

Since getting the GUI working, I have also finally got around to adding more advanced features to Pngcam, such as ramping on plunge cuts to reduce tool load, skipping out cuts on the flat top surface of the material, reordering cutting segments to reduce time wasted on travel moves, and producing an output heightmap showing what the material will look like after one operation so that it can be used as input for the next operation to stop wasting time machining air.

I've also reimplemented Pngcam in Go, partly for performance reasons, and partly because Go binaries are easier to package in an AppImage than the Perl scripts were.

(The problem I had with the Perl scripts was that they used GD to handle images, and GD is an XS module that uses libgd. So I dutifully packaged libgd.so.3, and GD.so, and wrote a wrapper script that mucked about with LD_LIBRARY_PATH to get it to work, and I succeeded. Great success! But then I tried to launch the program on a different computer, with a different Perl version, and it didn't work, because XS modules are tied to the Perl version they were built against. So then I worked out how to package a matching Perl installation in the AppImage as well, and I expect that would have been enough, but it seemed very distasteful, would be very annoying to update, and added about 20 megabytes to the size of the AppImage.)

What's good about it?

Meshmill's primary feature is that it is (intended to be!) easy to use. Importantly, this includes "easy to install": there is no compiling and no dependencies, you just download the AppImage and run it.

I have found other options for open source 3D toolpath generation very difficult to get started with, to the point that I have never succeeded in generating a 3D toolpath except with Pngcam and Meshmill. If you are already using a different open source 3D CAM program: chances are it is better than Meshmill and you should stick with it. If you haven't had success with other open source 3D CAM, you could try out Meshmill.

What's bad about it?

Despite recent improvements, Pngcam's planning is suboptimal. It still spends more time on travel moves than it could do if it ordered the cutting segments more intelligently. (Ordering cutting segments optimally requires a Travelling Salesman Solution, but I'm sure it could reasonably do better than it currently does).

It can generate travel moves that touch the surface of the part, which in combination with the "omit top" setting, can result in taking small gouges out of the top surface of the part, if the Z axis is zeroed slightly below the top surface. See my sake set picture below for an example of this.

There are still some very useful features missing from the GUI, primarily:

some way to generate hold-down tags
a way to rotate the part to more faces than just top and bottom (probably I'd aim to duplicate the PrusaSlicer UX here)
a way to start from a heightmap instead of an STL model
a way to export the "stock" heightmap from one job and import it into another

My sake set

The first part I have made using Meshmill is this:

It is an insert for a box to hold my sake set (a jug and 4 little drinking cups).

Wanting to make this part is what finally pushed me to make the GUI for Pngcam in the first place, so I'm glad I've now succeeded in that sense. Hopefully that doesn't mean I've got what I wanted out of Meshmill and will entirely stop working on it now!

I'm going to coat this part in flocking to give it a fabric-ish texture, and build a box with a lid around the outside.

If you like my blog, please consider subscribing to the RSS feed or the mailing list:

James Stanley