Questions about custom tool libraries, stepover, simulation rendering

[boulder_ben (Benjamin Cunningham)]

So, I had a couple questions about adding custom tool libraries.

I’m current working on a project that I initially designed using the Carbide 102 1/8" end mill. Unfortunately, since I am making some 21mm deep cuts, and the 102 end mill is only 1.5" long, I had to pull the end mill nearly half way out of the collet in order to be able to make the cuts. I know it’s not a great idea, but I did it and it worked. I did order some longer 1/8" end mills though so I don’t have to do it again. The new ones are 2 1/4" long, so I can safely use them.

When I add the new tool info to a custom library however, there are a few weird things that I haven’t been able to figure out yet. The process I used to create the new tool library:

1. open carbide create
2. open the tool database
3. copy the #102 from the Carbide 3D - Shapeoko - Hardwood
4. create a new library
5. paste the #102 into the new library
6. open the Carbide Data Directory > Tools >
7. open the new library .csv and plug in the new info

Here’s a screenshot of the library (since I can’t upload the .csv file for some reason)

As far as I can tell, the info should be identical to the #102. The only difference being the longer OAL, which isn’t even a field listed in the .csv file

Below is a screenshot of the default speeds & feeds when selecting the #102. Notice the 1.587mm (1/16") default stepover.

and the simulation when using the #102

Now the new tool. For some reason it defaults to a .200 stepover? All the other speeds & feeds are identical except the stepover? And I don’t see a 2D stepover field in the .csv anywhere so I assume this default is being calculated somehow? Why would it be different than the 102, which is what I copied? Is there a way to get the same default stepover that the 102 has set?

Next odd thing is the default render changes (using the .200 stepover). There seems to be some material left over in the bottom of the pockets.

And if I use the new tool again, but just tweak the stepover and set it to the same as the 102 (1.587mm / 1/16"), there seem to be some material or rendering artifacts left over in the pocket.

My gut says that the problem lies in the custom tool library that I made somehow, but I don’t know where.

• Any ideas on changing the default stepover?
• Or why that would cause some strange renders/simulation views?

[Tod1d (Tod (with 1 'd'))]

Tool length, even if it were there to specify, doesn’t get used by the toolpath processors.
The only geometric parameters that matter are diameter, and angle for vee bits & engravers.

Stepover also doesn’t get used. All new toolpaths default to 50% stepover.

[boulder_ben (Benjamin Cunningham)]

Hey Todd, that’s good to know. Thanks for the info! Any ideas on why the stepover would default to .200mm in this case? In the .csv, the diameter is set to .125" (3.175mm). Using the 102 endmill, the stepover is correct (.0625" or 1.587mm). But when I use the new tool (which is also .125" (3.175mm) the stepover is defaulting to .200mm instead of 1.587mm for some reason?

[boulder_ben (Benjamin Cunningham)]

Maybe a bug in how the custom tool libraries measurements are being parsed somehow? That might explain the strange simulation renders as well? If there’s a small bug either reading in the values or in the first few tool measurement calculations afterwards, that could result in an incorrect stepover being calculated. Maybe the simulation render is actually rendering things correctly, but is just using some bad inputs?

EDIT: no bugs, just user error See solution below.

[boulder_ben (Benjamin Cunningham)]

And… I figured it out. Dumb mistake, but I’ll leave it all here in case it helps anyone else out.

In the .csv, the angle is referring the actual angle of the end of the end mill. When tweaking the .csv, since there are a bunch of other unused fields, I just plugged in the helix angle (for the sake of being thorough). Since it’s just a flat end mill, it should have been left as 0.

And that explains the weird renders as well. It was rendering as if it was using a V-bit instead of flat end mill.