It’s various ideas for joinery — I’ve posted OpenSCAD renderings of them here in the past I think — or just the relieved finger joints for the magazine rack — it really shouldn’t be necessary to create two additional paths for each finger in order to get the desired result.
you could do the beziers in the csv as well something like
1, 1, 1,
1, 4, 1,
1, 5, 2, Q
2, 6, 3,
where the Q point is the quadratic bezier inbetween point. 2 Cs for cubic curves… also not a big deal.
for now I would end up making those discrete internally (but with small steps) since I’m quite scared still of G code arcs. (I needed this anyway for SVG parsing… you’d sort of end up specifying a 3D SVG 
1 Like
ok this is now working… wasn’t all THAT complicated it seems
the following CSV
4 4 -0.4
4 8 -0.5
8 8 -0.3
8 5 -0.2 7 5.5 -0.1
4 4 -0.4
gives as toolpath (with bit 102)
./toolpath -t 102 test.csv
test.nc (1.4 KB)
a 2nd example:
4 4 -0.4
4 8 -0.5
8 8 -0.2
8 5 -0.3 6 4 -0.5
6 9 -0.4
gives test2.nc (3.0 KB)
normal points are just given as 3 values, the 6 (or 9) value lines are beziers
the file can be comma or space separated, either works
(for the example I forced max depth of cut of tool 102 to 0.1mm so you can see multiple paths)
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
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
4 Likes
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
4 Likes
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
5 Likes
@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
2 Likes
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)
2 Likes
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 !