fix worked
also implemented the V-bit depth of cut. This works different than carbide create.
In carbide create, the V bit always travels the center of the “V channel” for “not final depth” paths, while in this tool the vbit will hit the side walls of the channel on each side. This allows you to cut a deeper V carve than your bit is high, which is common for the 1/4" bits that just have a sharp point
FYI I just stumbled on this that helps clarify the chipload vs chip thickness definitions and proposes a different(?) HEM strategy.
your link seems to hate me
OOPs fixed it -sorry and thanks for letting me know!
interesting read but… that’ll be curious to implement.
I first need to implement adaptive pocketing at all, never mind get clever about it. Now that vcarve inlays work it’s next on my list together with rest machining, which needs a lot of the same internal logic to figure out how much material is going to get cut (rest machining just eliminates the path if the material amount is 0)
For what it’s worth, I was working on adaptive clearing toolpaths in TPL a while back:
might be some information there which you haven’t found yet, and the code might (or might not) be useful.
thanks! will go through it in detail
a week or so ago you mentioned you’d like a tool that can do custom depths based on (non closed) paths… I might have time to build that into the tool before I figure the adaptive side out… can you sort of describe more of what you imagine?
I was assuming, you draw something in inkscape or carbide create, export as svg and then have some way to set start and end depths
(in inkscape you can label/annotate paths)
Yes, that’s it.
Consider this:
I’d like to be able to select each node, and assign a different depth to it — for bonus points, allow this to be done to curves.
Are there common depths?
Eg would using color in the design and then a color to depth table be helpful or hurting
(Bezier curves are not harder than lines)
This has been a fascinating discussion to follow. It could be interesting if C3D could give some hints about how to develop things that could be easily added to Carbide Create without disclosing any proprietary info, and then add them to the free version along with some protection for the developer. Probably plug-ins/post processors is too big a nut to add but making it easier to let them be added as the developers find time could be of real benefit.
If you look at the files for Carbide Create, you can see that post-processors are in the works — they’re kind of necessary for the Pro license to be marketable to folks who don’t have Carbide 3D machines.
I’d really like to see scripting or a plug-in architecture added to Carbide Create — we’ll see.
that⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
I’d vote for plug-ins. Being able to specify which area the plug-in applies to (pocketing, v carve, etc) superficially appears to be tricky, but I’m retired and quite happily forgetting those kinds of details 
plugins can be hard, you need to have some sort of safe data exchange model between app and plugin, and that means you cannot just change your internals anymore as easily… I can see why the C3D folks hesitate on that.
I would be fine with the overhead of writing out a file and interacting with the file, then re-loading it.
Maybe they can be convinced to do an NDA and let you work some magic on CC or perhaps both of you can come to an agreement to adapt your code into CC with something like a portions contributed by credit
There’s been a recent bit published on this sort of thing:
and see the video linked in the discussion.
I saw that before… the title was more interesting than the content, meaning, there was a “hey look in an FFT you can see something” but not a “and this is what it means”
but yes I put using audio as an input on my (getting longer) TODO list
Today I had some ruined pieces as part of trying to get pictures of the difference between CC, my tool with and without finishing pass… the CC cut sounded aweful in one corner and ended up with damage there, while my tool ended up getting the piece loose from the workholding. Woops.
So I did an emergency implementation towards more adaptive-style behavior, by slowing down once you’re within half a tool diameter of a corner… real adaptive is next on my todo list still.
A second set of cuts done (results below) and I must say that the CC cut sounded much worse, in corners and in the cutout (exactly where the bit goes down to the next ring) there were little bits where you could hear that suddenly the forces are higher… cringing kind of sound.
Spiral based cutout (as the tool has) is just one smooth cut… no bad sounds anywhere. And the slowing down for corners took the bad sounds out of pocketing.
Anyway, results with pictures:
C2D file including toolpaths:testcut-square.c2d (52.0 KB)
Which is exported as SVG as well for my tool: 
The results:
CC gcode file:
testcut2-square-cc.nc (65.1 KB)
CC inside pocket:
New tool, inside pocket
New tool, side wall:
Clearly I had set the stock-to-leave to be too small (0.1mm), will play with that more… but the result is clearly smoother as a result of the finishing pass.
(all 1/4" bit, 0.05" DOC with 60IPS feed rate)
@WillAdams Thanks for posting that! A high quality, reasonably priced (for ATC) HF spindle actually made in the US! Also, I’ve been using Audacity for years and never realized that it had a spectrogram display option!
