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)
test101.nc (275.6 KB) test102.nc (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
using:
./toolpath -t 102 test.csv
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
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
- Used https://touchterrain.geol.iastate.edu/ to create an STL file of a geographic region (a hilly section of Portland, OR)
- 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
-
Fed the gcode file to Carbide Motion
-
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).
Since actual feedback is … complicated, I was planning to make some sort of model and use that to control feed rate. Assuming the model is close enough to reality that should work