Cool!
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).
Cool!
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)
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
First real cuts of STL files
./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).