My project crashed right through my tabs today. Frightening.
The wood is .471" thick, so I set my contour cut to .475". Was that too much?
But it should not have gone through my tabs (5mm wide x 3mm high).
I did set the retract height to .25, is that what did it?
See my code attached.
Thank you.
1 clamp tabs chamfer test 2 lines.nc (28.5 KB)
One possibility is that the Z axis crashed at the top upon the initial retract, which then messes with the Z zero reference, but it’s a bit unlikely that this would happen with a 0.5" stock and 0.25" retract. Can you confirm you had enough clearance on Z ?
Was the cut ok initially, or did it start by immediately plunging way too deep on the first pass ? (which could indicate a problem in the zeroing procedure)
The initial cut was fine. I had enough Z clearance.
I thought the “retract height” was only the bit clearance above the stock and has nothing to do with zeroing. Is the “retract height” default .1"?
It doesn’t, I was just mentioning two possible (and independent) causes. The retract height has no impact on zeroing except…in the case where there is not enough Z travel left and the Z axis collides at the top, which then makes the motor loose steps, which offsets the Z zero. But since the first pass was fine, (visually did it cut at 1mm depth per pass as expected?), it probably not that.
Can you elaborate on what happened exactly and when during the cut ? How deep did it cut in the end ? Maybe post a pic, it might gives us some clues.
Were you cutting a slot?
If so, adding geometry so as to cut as a pocket down to at least tab depth will help:
The cut was going well, waiting for it to cut the tabs, but it just kept going.
And went right through the tabs, therefore the piece came loose and got jammed between the sweepy and bit! It never finished, bc I hit stop.
It cut the slot first and then was making a contour cut around the perimeter.
Weird…the moves to avoid the tabs are present in the G-code,
so the only thing I can think of would be an incorrect Z zero, resulting in a first pass being ~3mm deeper than it should be (and then it would cut down to stock bottom before reaching the cutting depth where tabs would have started).
Is there any possibility that you mistakenly run a different version of the G-code file that did not have tabs ?
Sorry for not being more helpful, but when the cut does not behave like the G-code preview, it’s either something mechanical, a wrong Z zero, or not running the file you think you are running (happened to me multiple times…)
It’s the right file with tabs…
It was most likely my zero setup.
I did change from a 90 deg bit to a 201.
But, I used the bitsetter.
I did use the 90 deg with the touch probe to zero it.
When you used the BitZero how did you have it placed?
Did you change bits right before you set z zero? It needs to go to bitsetter first after changing bits before setting zero or it will be off. I found this out the hard way
Ok, let’s review the zeroing process again.
I installed the bit, used BitZero, them hit Start.
Asked for bit again, used Bit Setter, then hit Start. Wrong order? Should’ve ran BitZero again?
You shouldn’t need to use the BitZero a second time, so long as the tool change was started by requesting it in Carbide Motion.
The machine does a bitSetter probing when you initialize it, with whatever tool was loaded at the time. When you say “I installed the bit”, did you change the bit that was installed at machine initialization, and if so did you use the “change tool” command to do so ?
The one pitfall in the BitSetter workflow is that if you physically change the bit without telling CM you did (i.e. without using “Change Tool” every-single-time), you can end up in a situation where the BitSetter probing adjusts the Z zero incorrectly. In that scenario, when you will start the job and it goes to BitSetter probing, it will apply an offset based on the tool length measured during the latest triggered probing, which was in fact during machine initialization, but you actually changed it afterwards behind its back so the actual tool length is different now. You end up with an incorrect Z zero.
So, always use the “change tool” menu when you need to change the tool outside of a job (it’s not necessary during the multi-tool job itself, because then it’s the machine prompting you to change the tool, so “it knows”)
I initialized the machine, then installed the bit, used BitZero/touch probe, them hit Start.
Asked me to LOAD the bit again, it automatically went to the Bit Setter, then i hit Start.
Did I do it correctly?
When you installed the bit at that specific moment, right after the machine initialization, did you use the “Change Tool” menu in CM ? If you didn’t, it could be the reason for the offset in the cut later
You could be right.
Let me retrace my steps again and run a test.
Thanks!
I would say that was your problem. Thats exactly what I did. When you changed bit without telling CM you did It assumed you were using same bit it measured on initialization. Then remeasures after zero is set when you start. It took me a little while to figure this out but it makes sense
I initialized the machine, asked for new bit, installed it, then, it automatically setup the bit via BitSetter.
I jogged it over and ran touch probe/BitZero. Then, it asked for a bit change again! Why?
The bit should be ready to go, yes?
Anyhow, the correct bit was already installed earlier, then it did the BitSetter AGAIN.
Finally hit start. Everything seemed fine, but over-kill on the BitSetter don’t you think?
Anyway around it, two rounds of BitSetter?
The machine has to measure the endmill each time it has not had control over the endmill.
Yup Gary…What I do is try to remember what the first bit is that I’m going to be using and use it to initialize the machine.
But if you don’t get it right, as soon as you load the project and you see what the first bit will be, click “Change Tool” and swap to that bit. Then start your job - which will re-probe - and you’re done.
It’s from the dept of redundancy dept.
