As explained in this video, measuring router input current isn’t a good way to measure power.
There are two approaches for pocketing in VCarve: Offset and Raster. I find that the best approach for pocketing in VCarve is to use the offset toolpath. It starts from the middle with a ramp-down hole then moves in a pattern that expands following the external contour so the engagement of the endmill is only at the stepover rate. In the raster approach, the endmill will make its way from one side of the pocket to the other starting with a full WOC engagement.
1 Like
interesting; I’m surprised the current software does not do this, since it’s actually easier to implement than the “inside out” path. The inside out path you actually create by doing the outside in “rings” until there’s no more rings left, and then play it back in reverse to create the inside-out gcode…
wonder why this is
What if it’s a rectangular or oblong pocket?
yeah RMS and all that…I’m an electrical engineer by training so at least I’m familiar with the theory of that part of things.
I did manage to measure both types of toolpaths, and subjectively there is more spikes in the carbide create one but I had in my toolpath creation the speed for the paths where the cutter has full engagement set to 66% and based on the measurements that was too high.
Still pondering if I should change it to a “half depth of cut” at normal speed instead of reduced speed at full DOC
You might find this calculator useful for such tradeoffs. I’d suggest maximizing router speed (RPM) to reduce forces and not worrying too much about chiploads. @Julien and others would probably disagree.
interesting that your rectangle in offset mode shows the potential of having the same issue CC had and leaving a little ridge, or at least fuzz…
Not anymore, I’m on the @gmack train now, maxing out those RPMs and increasing FR accordingly 
But to be honest, I only moved away from using slower RPMs after I upgraded to a water-cooled spindle, which is very quiet compared to a trim router screaming at 30.000RPM and annoying the neighbors. That sound was unbearable to me…
And about using ‘low DOC, high FR’ versus ‘higher DOC, lower FR’, I now choose…higher DOC and higher FR, using adaptive toolpaths, whenever pocketing. For pure slotting/profile cuts I will tend to go shallow and fast, if only for peace of mind, and the satisfaction of seeing the machine move fast.
4 Likes
Code is now on github:
still a lot of cleanup needed but in case folks are interested.
it’s more a toolkit to play with toolpath generation than it is a production tool of course
2 Likes
I guess we’re missing something! Seems like an obvious (and easy?) way to achieve some HEM advantages to me. But, unlike you, I’m not a software guy. 
Ok so having played with this a lot more, turns out there’s an even simpler solution to the problem, something simple and low risk enough hopefully the Carbide 3D folks will consider it.
So problem again looks like this:
where the toolpath generator makes increasingly small “insets” and at some point hits a place where it cannot do another “stepover” sized inset and concludes it is done. At the limit of this you can have a whole tool diameter gap and you can imagine the cutter just barely missing, or at least leaving fuzz.
The interior skeleton approach, while hitting all problem paths, has complications, it’s tricky to compute and there are many paths it follows that are not actual problems.
So the more easy solution is this: Once the generator, while generating those insets at stepover, hits a point where there is no next inset anymore, instead of giving up, it tries a half stepover inset. If the original insets were close enough together (e.g. within normal stepover) this leads to no new toolpath, but if there is a larger gap, it gives a very nice simple fix:
In the limit, the distance between the two lines above now is exactly one stepover distance, which is more or less the desired outcome in terms of finish quality…
and as I described it, this is really simple to implement, instead of stopping, just one more try at half distance.
Now this will miss some cases, for example it will miss the area pointed at by the arrow below
which has the same effect occuring just not at the final round of making the insets.
with a slight tweak to the algorithm I described those can also just be dealt with:
but even if this fancy version is too complicated for the Carbide Create folks, I’m hoping they are willing to consider the more simple version since that takes care of many of the issues at very low complexity
3 Likes
Why not just overshoot (air cut) the innermost cut?
do you mean to basically do an extra full stepover inset always?
(that’s… complicated a little bit in the math)
also normally CC will cut these from the inside towards the outside
Aren’t you proposing a way to pocket from the outside in rather than inside out as currently supported by CC and Vectric? Is the math harder than the alternatives? Is there some other downside of always doing an “extra full stepover inset”?
the code right now follows the inside-out, but… that’s just to copy what CC does. it’s more work (not much but still)
The way any of this is done is that the math is done outside in, and then the order is inverted when gcode is written. But it’s by no means fundamental … yet.
I’m about to play with adding a way to have a roughing tool and a finish tool (or multiple of each) in a way that you do relatively efficient rest machining, and once you do that, inside out likely makes the most sense (start with the largest bit, clean out the most then go to smaller and smaller bits for the details)
going to a full “overshoot” I will need to check if and how that can work; the perfect “just do a line through the middle” is easy, but that was the original “skeleton” approach… I have that coded but not sure the CC folks can deal with the complexity of it
2 Likes
btw just to be clear, I’m not trying to replace Carbide Create… I actually really like CC. I’ve been using it for the better part of a year now and have realized that with some small tweaks the resulting gcode could give better results, from the same input/everything else… and I decided to prototype how that would work (both because it’s fun and because I don’t want to ask for something that turns out to be impossible)
So far what I would like to see in Carbide Create’s gcode generation side
- Run the “move from one poly to another” gcode at half speed since it’s known to have full cutter engagement, and it seems this is where runout/deflection effects get most visible. The distance is also small obviously so no significant total cut time impact
- Solve the “fuzz / ridge” issue, I’ve shown 2 different ways to solve it with different levels of impact/complexity… pick any or something else
- Would be really awesome if there was a “finishing pass” checkbox, but this is also a UI change and I respect the desire to keep the UI super simple
- Even without a finishing pass, making the stepover of the outermost cut half of normal should give a nicer looking finish without increasing cutting time a lot
3 Likes
IMO, at least for rough pocketing, outside in makes the most sense because it prevents problematic cutter radial engagement angle increases during direction changes. This enables greater fixed depths of cut and feed rates for the stepover passes, as do HEM and adaptive clearing toolpaths/strategies.
For wood, it also enables the use of larger diameter straight cutters for cleaner cutting and lower forces.
2 Likes
fair enough… I’ll build both and play with it… of all the hard things, this isn’t it
1 Like
just an update; implemented the option for outside in pocket toolpaths. Also added basic V carving support to the code. Next is a vcarve+normal tool combo where you set a max depth for the vcarve and do a pocketing operating for the deeper parts.
(once that is there it should be possible to layer on a inlay option where the single export file from carbide create gets turned into 2 gcode files, one for the inlay hole and one for the plug)
I also need to work on the remainder of cut quality stuff, but my XL is out of tram due to a collision between hdz and bitsetter and need to finish rebuilding it more or less since something is off and I don’t know what quite yet.
3 Likes