So I have been using this for quite awhile on both a S04 and now my pro. I use 3 bits all the time and 1 bit is shorter by about 1mm than the other 2. When going from the longer bit to the shorter, the bit setter doesn’t seem to account for this and it cuts too shallow.
My question is, what is the proper sequence to use this? My current work flow is this:
Load gcode file
Set Z manually
Run the file and let the machine do its thing.
I have started running these the same length bits in one file and the shorter one on its own.
Did you follow the instructions in the manual for enabling the bitsetter option in carbide motion?
I did it just like they said. Every time I initialize the machine and every time there’s a tool change command, the machine makes a trip to the bitsetter and measures the length of the tool.
Are you generating a single G-code file that has all toolpaths for all three tools ? (your last sentence makes me wonder)
The BitSetter (when it’s enabled) should work fine if you stick to those rules:
make sure you have the “Carbide3D Shapeoko” post-processor selected under Edit / Select post-processor
generate a single gcode file in CC for all your toolpaths, and run that
never ever (ever) swap the tool without CM prompting you to do so, or explicitly using the change tool button. That applies from the moment you initialize the machine and its does its initial bitsetter probing.
Everything works as it should. CM prompts for the tool change, I change the bit, it measures the new bit and then continues on and runs the next tool path. What it’s not doing, is accurately measuring the new bit. In most of my scenarios, the shorter bit is not cutting as deep as the longer bits do, which the longer ones are cutting at the correct depth.
So my question is why isn’t CM and the bit setter not accounting for the difference in bit height when that’s what it’s for.
This is why we are asking lots of questions: in many similar cases, it turned out that it was a subtle thing in the workflow that was not quite right, and it’s often the elements that people don’t mention (because they think they are irrelevant, or are not even aware of them) that end up being the problem.
If you can easily reproduce this, that would be good news and then it may be easier for troubleshooting to capture a video (from machine initialization to when the problem happens) and work with support to figure out what’s going on.
It’s very easy to reproduce. It happens every time i use these bits, which is 99% of what I cut on this machine.
Unless I am not aware of a certain procedure, for example, use the load tool function in CM, load the file, then set the Z and run said file, or set the Z, then load the file, then run the load tool, then run the file…
Other wise, it seems that CM has a bug in its tool length method in CM.
I use vcarve pro with the PP that does the tool change option.
If you’re following the procedure in the blog post I linked, the only other thing I can think of is that the bit is so short, the Z is running out of travel.
Maybe you can tell us what your procedure actually is?
It should be:
Turn on machine, then connect and initialize in CM
Wait until the spindle comes forward there’s a prompt for a tool to be inserted
Make sure there’s a tool and continue
Set your zero
Load a file and run it
Wait for CM to ask you for the correct tool, install it, and continue
Do 6 for as many tools as the job requires
Loading a file is not relevant to any bitsetter operations or zeroing. It does nothing other than fill an internal buffer with what gcode will run next.
What you shouldn’t do is think that the BitSetter is measuring your tool arbitrarily. It does not do this.
My procedure is exactly what you just posted. I wanted to be sure my process is the correct one, and it appears it is. Hence why I think there is a problem on the software side. I’m a software engineer for 20+ years. I’ve had to interact with hardware (not cnc related) and I’ve seen my share of issues where the hardware and software aren’t exactly in sync.
As for DOC for the last bit, same as the previous bits. I cut a lot of flat parts out of carbon fiber. I use 3mm, 2.5mm, 2mm and 1.5mm bits almost exclusively. The 2.5 and 1.5 are a little shorter than the 3 and 2mm. I’ve started grouping tool paths based on bit length because if the bits aren’t the same length, it doesn’t cut correctly. It also doesn’t matter if it’s a pocket, a contour, a drilling operation, it’s never correct.
I guess the reason why most people want to find out exactly what you are doing is that there are lots of people using the same hardware and software and are not experiencing these issues. Most of the time it turns out there’s something wrong procedurally.
The length of the bit is probably not that important, since you are unlikely to get it in the same position in the collet each time you run the job (unless you ram it up till it stops moving every single time?)
Anyhow, if you are only ever changing the tool when there is a prompt for you to do so in CM, then then some one other thing to check is to see if the bits are slipping in the collet (you can test this with a marker pen)… this can happen easily if you put a 6mm shank bit in a 1/4" collet, for example.
They aren’t slipping. Cutting carbon, if the bit was slipping, it would fail completely, especially with the 1.5mm bit… those will break very easy. to say the bit length isn’t important is crazy to me. if I use the same length bits, they cut the same (the bits have collars on them, yes, I could make a jig and make sure they are all the same length, but that defeats the point).
I’ll keep trouble shooting as it has to be something…
I wondered about bit slippage as well. Are you changing collets with each bit change or do they all have a common shank? Is it possible that they are all 1/8" except the ones you are having problems on and they are 3mm instead?
Either way, if I would try loading your first bit like normal and setting your Z height. Then, using CM, change to the short bit and have it set the length and then carefully jog down over your part to Z=0. If your problem is with the bitsetter and 100% reproducible, this should hit the part before reading Z=0.
Doing this check will determine if your bit setter is just misreading these bits for some reason. There’s no inherent reason this should be a problem though as I am often using 1.5mm, 2mm, 1/8", 1/4" bits all in the same file without any issues.
Bit length has been an issue for some folks who have used really short tooling for very deep cuts — this isn’t likely to be a problem on a current machine, but came up quite regularly on SO3s.
Best practice is to set the zero initially using the shortest tool, and then verify that the machine can move low enough to make the deepest cut expected.
Usually not cutting deep enough is caused by:
endmill too short to reach
feeds and speeds off so that the machine can’t manage to cut as deeply as it needs to due to lost steps
configuring for a Z-Plus when one has an HDZ
file has origin at bottom of stock, but setting zero at top
Anyone who continues to have difficulties should send in a .c2d file, generated G-Code, step-by-step notes on how they are setting zero relative to the stock and managing all tool changes and a photo showing an attempt at cutting still in place on the machine to support@carbide3d.com and we’ll do our best to puzzle things out w/ them