Cutting forces with Carbide Create -- and how I got derailed a bit


Previewing looks a bit odd in CAMotics:

I’m now wondering if it is possible to have an arc which is not wholly in a defined plane (still reading through the G-Code standard).

Need to make a more interesting csv, mine was tiny
(Units are in mm)

How about one which will make a simple circular depression?

Say something which would allow cutting the marble spots in:

you mean something like this (I did both bit 102 and 101, my camotics seems to hate ballnose today) (275.6 KB) (275.6 KB)

$ cat test.csv
20 20 5 10
20 50 5 10
50 50 5 10
50 20 5 10
0 0 -4
0 70 -4
70 70 -4
70 0 -4
0 0 -4

./toolpath -t 102 test.csv

1 Like

Sort of, but I was imagining polar toolpaths — imagine cutting a hemisphere like to a globe buried halfway — each line starts at the equator, passes through the South Pole, and comes back up at the equator on the opposite side of the planet — one wouldn’t need the full 360 degrees of longitudinal cutting, but some reasonable number should result in a smooth hemispherical cutout.

Looking through the G-Code spec now to see if the sort of thing I want is even possible.

If it isn’t, I guess I’m going to be working out the math to represent the arcs as polylines, at which point I might as well do Bézier curves.

I thought about doing the paths that direction but for large spheres I wasn’t sure it was a good idea; the southpool runs the risk of lots of overmilling… but I can ponder it more… especially if you can do the whole thing as one or 2 G code commands (not unreasonable to have a separate command for equator-to-pole and pole-to-equator)

as far as the number goes, likely just moving with a single stepover (measured at equator) cold work

also since usually the feedrate is higher than the plunge rate by quite a bit… wouldn’t a more horizontal approach cut quicker

spent some time this evening to make a windows port; precompiled binary available at

it’s extremely lightly tested (compared to the native linux version)

the toollib.csv is my normal carbide create tool library… replace with your own


next up: create some basic docs

1 Like

next feature implemented: STL files

excuse: was easier to add than adding rest machining/adaptive tool paths

  • supports > 1 roughing tool in the same toolpath
  • runs the final pass at 90 degrees from the roughing passes
  • an optional “finish” pass will run 2 final passes, 90 degrees from eachother
  • does not require a lossy translation to a grayscale depthmap as intermediate phase

First real cuts of STL files

  1. Used to create an STL file of a geographic region (a hilly section of Portland, OR)

  1. Fed the STL to the Toolpath tool:

./toolpath --cutout 0.75 -t 201 -t 102 -t 27 --stock-to-leave 0.33 geo.stl

Where tool 27 is a 0.5mm radius tapered ballnose

Camotics view:

the conversion was surprisingly not slow (30 seconds on a laptop) with the STL model having 617392 triangles

  1. Fed the gcode file to Carbide Motion

  2. Put some oil on the wood

I’m pleasantly surprised that the streets/house blocks are even visible in the wood cutout.

Next time I’ll decrease the stepover a bit, and maybe turn on the finishing pass


@fenrus This is really cool. I had some time to play with it and it was surprisingly fast. I did have an issue with a terrain STL…I’ll see what I can repeat.

How would you do that?

Also, what would a command look like if you were to NOT cutout the model?

I need to add command line (or config) tunables for either; I’ll try to get that done on my commute home today
The not cutout I need to think about, I assumed a cutout was useful to protect the fragile small bits later… but I’m also fixing that in another way.

Made a new release including @neilferreri’s requests; now you can specify the stepover on the command line.
(The default stepover is also half of that of the previous version, so compute takes longer)
You can now specify --depth if you don’t want a cutout toolpath

toolpath --depth 0.75in -t 201 -t 102 -t 27 --stock-to-leave 0.1mm geo.stl

like that


What does that mean? Why does the depth of the workpiece matter?

Thanks for continuing to develop this!

STL files don’t really have a dimension, so I use the depth of the wood to scale the STL vertically to fit that (for horizontal I then keep the same aspect ratio)


I finally had time to read this paper, and it’s quite interesting indeed. I’ll now wait for @fenrus to implement chip thickness control in toolpath generation in his ongoing (and impressive) CAM endeavour !

All that effort for inside out (vs. outside in) pocketing!

made a new release just now, performance is much more reasonable in this release. The previous release (with the reduced stepover) would take 1 1/2 minutes to compute the geo stl file, the new release does this in 8 seconds.


An interesting alternative approach - using cutting power feedback to dynamically adjust feed rate. As explained here, cutting force is proportional to machine force (which is typically what limits CNC router performance).

1 Like