"Helix" cutting

I’m on the Origin Shaper mailing list (neat device, but above my price range), and their latest update includes something they are calling “helix” cutting… in essence continuously changing the z-axis to cut deeper as the machine moves in a small circle (to cut a hole for instance). Seems like something that might be feasible for a Maslow in certain instances - so that you don’t have the “stop, adjust z-depth lower, cut some more, rinse, repeat” cycle…

Thought I would mention it in case it sparked an idea for the smart folk :slight_smile:

1 Like

That would be a feature of the CAM tool used to generate the G-Code. I can’t think of any reason Maslow couldn’t do this. I think I’ve heard this referred to as a “spiral pocket” or something like that?

1 Like

I have done this as well as ramping (same thing, but in a straight line) and both have worked. Helix cutting, or “boring” as it is called in Fusion360, is definitely the quickest way to cut small holes with the Maslow.

1 Like

Maslow can do this kind of cut, I’ve had Fusion360 do it (once) before, although it needs to be enabled in the MaslowCNC post processor. It is disabled by default. As @TheRiflesSpiral said, its a function of the CAM software output, and not a limitation of the MaslowCNC machine. However, remember that the default Z-axis isnt quite as fast as the rest of the machine, and to adjust your settings with this taken into account.

hope this helps,


Thanks for the info… I guess part of the difference is that the Shaper has more “brains” onboard… it would be kind of like including this capability at the Ground Control level I think.

I’ll try to dig around in the CAM world and keep learning.


I want to add a caveat to this that I have found it easier and quicker to cut any small holes only ~1/8" to 1/4" deep to mark the spot, then drilling them out with a power drill after the Maslow is done cutting.

1 Like

FYI, EstlCAM offers helical pocketing and helical drilling.

1 Like

Ground Control is far too late. At that point, the job of the CNC machine is to
follow the instructions it has been given as precisely as possible. It’s those
instructions that tell you if you are going to plunge down to full depth and
then enlarge the hole, or spiral down, or do multiple plunge/enlarge steps.

Ground Control also has no way of knowing which of the many options you want to

The CAM step is where this is determined.

There are some people who would like to see GC become a CAM, reading in a SVG
and cutting it. I think this would be a mistake (at least for a good while), we
need the maslow folks working on improving the capability of the machine to
accurately and quickly follow g-code, not learning to generate g-code. At some
point we will no longer have such a huge list of to-do items and it won’t hurt
us to add things like that to GC, but right now, it would hurt significantly

Makes sense… At some point I think Ground Control should have a bit of “local control” for some canned shapes, simple straight cuts, etc. But as you say, that can be a long time down the road.

I agree. The Maslow is a CNC machine, and GC is a basic interface for that machine. I know that programs like Mach3 have canned routines (I’ve used them and they are great), but I agree with @dlang that we should first and foremost focus on having GC support the machine as efficiently as possible before adding bells and whistles.

for simple straight cuts, we should support two things (and these can go in now)

  1. a box that lets you type in raw g-code and it executes immediately (if it’s
    not running a file)

  2. a box/slider for how far to move when you hit an arrow key. run the Z down
    into the wood, and use the arrows to move

The value entry box and arrows are available now, you can run in etch-a-sketch mode if you like.
The command line would be nice to have, though.


I use FreeCAD to generate Helix paths. It allows drilling wide cylindrical holes to combine z moves and save time.
But as of firmware version 1.21, G2 and G3 arc move Gcodes used for helix paths are only implementing XY moves and do not plunge the Z at all. A Gcode export post processor might create multiple straight lines to emulate a helix, but I don’t have that and this would make the gcode file size grow fast.
So I forked and improved the G2 and G3 codes to perform helix paths. It works well. Note however that my fork cumulates several other commits such as renaming labels for clarity. And it has not been reviewed by peers yet.
So you might want to get into arcXYZMove() from Motion.cpp to get the example code.


How about separating all that into a branch for each change (rename, G2/G3, etc? It’s easier to test against more incremental changes.


The coordinated XYZ movement in G2/G3 works a treat - a great contribution! :100::tada:


:tada: :+1: :+1: :100: That would be a fantastic contribution if you are willing to make a pull request!

That would be great!

A branch for each change… still learning the git and github ways.

I have renamed labels… quite a lot. As a result, there are just a few but important (namely eeprm settings version 5)functionnality changes.

I finally merged to the master branch on my fork and here is the resulting announcement.

1 Like