Often when I zero my Z axis, then start to cut a project, the Z axis somehow changes and it will cut very deep.
When this happens I always check to see where the Z axis is set, and sure enough the Z axis is different than where I just set it. So I then reinitialize and re-set my zero a second time and it works fine. It does this 2 out of 3 projects randomly.
Does not happen with X and Y.
I set X,Y and Z manually at start of each project.
I use a bit setter.
Happens whether I load the file in carbide motion before setting zero or after.
No pattern on when it happens; 1st cut of the day, 2nd cut, etc.
Was perfectly fine for quite some time, my process has not changed.
Recently had the board replaced for a different reason, but it worked fine for 2 weeks after the board replacement.
Since you have a BitSetter, the most likely cause for this is the workflow for swapping bits.
You should always, always use the “Change Tool” button in CM when you need to physically swap the bit. It’s easy to not pay attention and change the tool in the router at some point and not tell CM, and even if you re-zero after that, you will still throw off CM Z zero adjustements, because CM will remember the tool length from the previous tool, and it doesn’t know you swapped it unless you used “Change Tool” explicitly.
If you stick to only ever changing the bit
a) when you get a prompt to do so
or b) after clicking on Change Tool,
you should not have this Z problem again (assuming your procedure for zeroing is correct)
To set Z axis I jog to a clear place on the project and us CM to lower the tool until it gets close. I change the movement parameters closer until at .0001” and use a thin piece of paper to gauge height. Then set z axis only.
Allright. The other “typical” cause for cutting way too deep is using a large retract height with thick stock, and running out of Z axis travel upon the initial retraction. Any chance this is what happened, when it happened ?
Is there any chance your “safe z” is too high? This would cause the z to try to retract higher than it actually can which makes the machine think the bit is higher than it actually is. Then when it plunges again it will go deeper than it should. If this is what’s happening, you would hear the z grinding at the top of travel, though with all the other noise, you may not notice it.
Sorry, I’m a bit confused, and the devil is in the details, so let me rephrase to see if I got this right:
You are loading a single G-code file, that has toolpaths for multiple tools (right?)
You initialize the machine, it homes and comes to the front, you load the first bit.
You then set zeroes manually.
You load the file and start the cut: the machine will go probe the BitSetter with the first tool loaded, and proceed to cut (is the Z depth sometimes wrong at that point ?)
The cut proceeds, comes to a point where a tool change is required, you get a prompt to change it which you do, and then…you mention you lower the Z axis and set Z, which is the part that confuses me since in a multi-tool job CM won’t let you do that and you should only have to “resume”? I must be missing something.
To be clear:
I load a single G-code file, that has toolpaths for multiple tools or single tool.
I initialize the machine, it homes and comes to the front, and load the first bit.
I then set zeroes manually.
I load the file and start the cut: the machine will go probe the BitSetter with the first tool loaded, and proceed to cut.
It is at this point the Z depth sometimes wrong.
I will stop the cut, and jog the machine to a spot on the project, then set zeros Manually again.
With the file still loaded in CM, I start project a second time.
Only on the first cut of a project, but not every time.
Are you able to reproduce the problem “easily/quickly enough” that I could ask you to grab the logs when this problem occurs ? (in the “Settings” pane, click “Open log” window, and keep it open, then if the problem happens copy/paste all logs)
Somehow, when the job starts, CM’s current tool length does not exactly match what the tool length sticking out of the collet actually is, so when it goes and probe the BitSetter upon starting a job, it detects a difference in tool length, and decides to compensate Z0 for that tool length difference (as it should), and then you end up cutting too deep.
When I have seen this reported, it was because the tool stickout had changed, either because the user changed/adjusted the tool manually, or because it slipped in the collet (any chance this might be happening here? unlikely though)
at this point I would suggest doing a “M6T201” command in the MDI screen right after zeroing.
(that will prompt for the tool change, and then do the bitsetter thing). After that, do a “G0X0Y0Z5”. That should put the bit exactly 5 mm above the zero point (which you can check by, in the job screen setting the step size to 1 mm and go down 5 steps)
If that already has the deviation… we’ve then narrowed it down a LOT