CC - New VCarve paths should default to Stock Bottom as depth

Right now the default depth for a new VCarve toolpath is, well actually I don’t know where it comes from. Just now on my machine is was .15", no idea why.

BY DEFAULT, a VCarve should be stock depth (.75" in this particular case, nowhere near the .15" it provided). People who know what they want can change it, but this question comes up almost DAILY on the Shapeoko Facebook group.

The .15" comes from the “settings” file. Open Carbide Create and on Help Menu click on About. There you can click on “Open Data Directory” You will find on Windows a file called “settings”. This is a text file and is the defaults used when you open CC. Most likely the last time you set a depth it was .15". The figures in this file are in metric because even if you select inches under the covers everything sent to the Shapeoko is metric.


The last project I was cutting .21 inches which is 5.334MM.

OK, that means when I created a new VCarve toolpath, the depth defaulted to the depth of a pocket operation from a completely different project!

That makes no sense. I don’t think it makes sense for a VCarve depth to be based on the depth any other type of toolpath, either this project or another.

Even for toolpaths of the same type, having those depths as the defaults for other projects isn’t very useful. These are exactly the kind of ‘default’ values that should be saved per project, not globally.

Whether it makes sense or not that is how it works. In some things it does make sense like retract height and a few other settings. The only other option would be for every setting to be set to a default that you might not ever use in your projects. Many times you are starting a new project but it is similar to the last project so the settings are repeated.

Unfortunately every time you make a tool path you have to check every parameter to make sure it will carve correctly. With settings being inserted from the last project I agree that it could lead to mistakes. However with experience you learn to check every parameter before saving your gcode.

The folks at Carbide3d are not mind readers and cannot anticipate every action every user will make. There are a lot of users and each one is unique to the way they approach making a project. So that makes for a lot of ideas on how the software should work. You can submit an idea for a request for feature on CC and/or CM.

Yes, for pockets there is no obviously always right default, but for a VCarve there is - just pick stock bottom!

And for the others, I think a better ‘default’ value for the depth is zero. I’d rather be forced to edit it to get it to do something than have it show up with values that came from a different project. Once you’ve picked a depth for that project, sure use that for further toolpaths.

And, this is a feature request. It’s in the Feature request category!

I’ve seen several posts that say to set the depth to stock bottom. This seems odd to me as if you’re saying you want to cut all the way through the stock.
I think I understand, “cut as deep as you need to make a bi-tangent contact with both sides of the vector we’re cutting.”
But it seems to me v-carve acts a bit squirrely when set this way.

Take for example the star from a recent post. When the cutter is between the lines on the ‘arm’ of the star, it can follow both lines, but when it gets to the center it would cut to the bottom of the stock.
I seemed to see the best results when setting the depth to the actual deepest point I want the cut.
For the star that would be the radius of an arc tangent to two of the inner-most points on the star.


When set to stock depth, it can cut through, or right up to, the bottom of the stock.

I use VCarve Desktop, and it has an Advanced VCarve equivalent.

It’s a little different in that it implements ‘rest’ clearance with multiple tools which is really nice. But it basically tries to adhere to the idea that “you want the pocket to be this deep, so I’ll make sure I do that”.

For me, the specific selection of the pocket depths is important since I either make brass or delrin debossing stamps for leather, which need at least 1.5mm but maybe 2mm depending on the design, or I later want to fill everything with epoxy.

So there is no rule for this, in my (limited) experience. Defaulting to that last thing you did makes sense since people tend to iterate over the same sorts of things.

I never want the pocket depth to be the depth of the stock. I don’t follow that much and would appreciate an explanation.

In this case, in CC an Advanced VCarve is probably what would be recomended. If you have areas of your carve larger than the diameter of your cutter, a VCarve isn’t going to give good results.

I’m talking about a boring old VCarve, not an Advanced VCarve.

Sorry, I misread. Why would you want to cut a regular vcarve down to the bottom of the stock?

You don’t ‘want’ it to cut to the bottom of the stock - you want it to cut as deep as needed to touch the bounding lines.

For a boring VCarve, the bit depth should be a function of touching the bounding lines, and not artificially limited to a shallower depth. If the graphic is such that there are areas where the cuttter is not bounded (and thus plunges through the stock), then Advanced VCarve should be used instead.

I had a peek at the current VCarve in the latest build.

It seems to be using some sort of calculation to determine the depth rather than the last value you last entered. For example, if I set the stock depth to 10mm it suggests 10mm as the depth. If I raise the stock to 80mm thick, it suggests 38.1mm as the depth for a new VCarve in the same project.

In that case should the request be to disable / grey out the max depth for regular VCarve? The max depth can be reserved for AVC where it is a legimate parameter?

I don’t believe this has been considered for a future release, but Stock Bottom isn’t stock bottom, but “stock bottom as at the time you clicked Stock Bottom”. If you subsequently change the material depth your max depths don’t change.

The Stock Bottom thing has been requested before, but I imagine the changes needed to make these values dynamic (instead of just capturing the value) would be quite substantial.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.