Apologies for reviving and old thread, but I’m having a similar issue and cannot figure out why this would be happening. I am cutting a very thin piece of stock, too thin to use the BitZero so I am setting X,Y, and Z manually. Once I start the Job Z is reset to too low and is plowing the bit into the stock.
Here are the steps that I am taking. Please note that I’m not changing bits at any time.
Turn on machine
open Carbide Motion
click Connect to Cutter
Click Initialize Machine
Machine homes and then prompts to change tool. The tool that I want to use is already installed (1/16" end mill) so I click Resume
The machine runs the bit setter sequence.
I then Jog the machine to the bottom left corner of the stock and set X and Y using the SET ZERO button and clicking the ZERO X and ZERO Y buttons
I then use the paper method to set Z, click the SET ZERO button again and click the ZERO Z button.
Next I use the RAPID POSITION button to double check that everything is correct. After clicking RAPID POSITION and both the RAPID TO CURRENT XY and RAPID TO CURRENT Z + 6mm I can see that the X, Y, and Z are correctly set to 0, 0, and 6.0 and the end mill is in the correct position.
Next I click Run and LOAD NEW FILE
Select the file that I’d like to run and click Open.
I then click START JOB and then START
I get the Tool Change Required popup prompting for the 1/16" bit that has been in the machine this entire time. I click RESUME
The machine checks Z again with BitSetter
I’m then get the Spindle Change Required prompt. I turn on the router and click RESUME
The bit plunges into the stock and cuts 3mm too deep
I click the PAUSE button and then the STOP button.
The machine homes again.
I then click JOG and RAPID POSITION
Then click RAPID TO CURRENT XY and then RAPID TO CURRENT Z + 6MM.
At this point I can see that the bit is now only 3mm above the stock even though the Z position says it should be at 6mm.
I never change the tool throughout this entire process. Any ideas on how this 3mm in Z height is lost?
This could be the issue. I recently upgraded to the HDZ and did update the machine configuration. I just checked it again however and you have to actually click the Load Defaults and Send Configuration buttons in order to see what settings were selected. The size of the machine did not change, so I did not click the Load Defaults button for the Travel Dimensions. Since I’m troubleshooting now I decide to click that button (thinking it would just reset to the same numbers) but instead I got a popup window showing the Z-plus instead of the HDZ. So maybe I needed to set HDZ under Travel Dimensions as well as Machine Type.
It would be very helpful if we could see what is set without having it hidden behind the button. The Load Defaults and Send Configuration Data buttons make it seem like they are going to perform just those functions when you click them, but instead you get popup windows with settings…
Now that I have HDZ picked in both locations I will do another test.
I’m not using a probing pin, perhaps b/c I have BitZero v1. But in this instance I’m setting all zeros manually. The machine is not bottoming out, but the bit is going into the wasteboard. I’m on HDZ so should not be losing steps.
The bit is sticking out only a little bit over the .5" minimum for BitSetter, so maybe that is contributing. I just discovered the .5" minimum, so add that to my memory logs.
OMG I’ve been having this same problem and it’s for the same reason! Thank you for the well-documented test! I am glad that you did it so that I don’t have to.
Julian,
I have not posted to this web sight since I started working with the machine 6 months ago. The Z axis problem is something I have seen sporadically. I now have a process of changing bits and doing the xy move then the 6mm above Z move. After breaking a few bits, I work with 2 and 1.5 mm bits a lot, the 3 mm and above don’t break they just make the Z axis grind till I emergency off. I now look for it to go below the 6 mm mark and hit the emergency off before it happens. Now this does not happen often. I use the machine many times a day and change the bit at least 30 or more times a day and it happens about once a month. There is a quirk after using the bit setter. I wish the machine software did not make you use the bit setter on initialization. Some times I want to go right to the bit zero. Damn it, I still must use the bit setter.
But that is not the point of this post. The point is I am a robot in working this machine now. I never have an issue, and I never have a problem, except the Z axis only after using the bit setter. And that is about once or twice a month. I will say I cut into my spoil board twice before I figured this out. Since I stopped trusting the bit setter it has not happened again. One day I will start doing some data dumps and look for info as to why, but I am too busy making things for friends, work colleges, and profit right now. Just a shout out that there is an issue here. On my machine it does not happen often and I have a method of testing prior to cuts so I have not ruined any bits or my spoil board in months.
Thank you, duly noted (and if you ever have a case where somehow you can determine repeatable actions leading to the wrong Z, that will be most useful of course)
Just to make sure I got this right: you are double-checking Z zero by using the Z+6mm button, with your hand on the emergency stop. But this is before starting the job, correct ? In which case any (infrequent) Z error would be related to the zeroing procedure, not the BitSetter, since the BitSetter adjustment happens upon starting the job (when it does the probing routine before proceeding to cutting)
Your questions first.
Yes before starting job. And I will disagree on not the BitSetter. 1. I add in my new gcode. Remember the zero was done on the previous bit and gcode cut. 2. I start the change bit process. 3. I change the bit for the new gcode. 4. It goes thru the BitSetter. 5. I send it to the xy. 6. I do the Z 6mm. 7. I start the cut.
Number 6 is where I have the issue. Very infrequently, but it still happens. I have never had the issue if I do a Zero with the bit I will use and then start the cut. When it happens it happens after a bit change.
I wish it was repeatable. That is why I got into t habit of the steps. I was looking to make it where it did not happen or the steps would let me see something repeatable. My next thought is to do a data dump. More work than I want to do right now as I will need a dump prior to running the bitsetter and dump after an awry event. That would mean at least 50 or more dumps before I catch an event. Not on my list of todos right now. Or I write an auto dump procedure to do it and trying to link it to dumping before using the bitsetter. This is also challenging to say the least. So definitely not a todo right now.
Understand that to me the issue is so minor and habits are now so ingrained that I would do the check steps even if the issue never happens again.
Just to add to the whole picture, you should also have:
8. it prompts me for the bit for the job
9. it does the bit setter
10. it starts to cut the material
No
When I hit start the cut at 7 it starts cutting. In number 2 I ask for the bit to be changed and change it. I have never had anything prompt me for a bit change. I am using GCode created by Aspire using the Shapoko(mm) Post processor. The only bit change prompt I get is when I initialize and it goes thru the bit setter almost automatically. This is what in the first post I said “I would rather it not do.”
It has to measure the bit after initialisation to get the current offset for the whatever is sticking out of the collet. Otherwise it can’t subtract or add the difference when the next tool is inserted (it never actually measures the tool).
Your order-of-operations differs from mine. The very first tool change in the project asks for a new tool, causing a bitsetter check at the start of a project after you have run it.
You sound like you only use one gcode file per tool rather than a single file running multiple tools, which is arguably the greatest value of the bitsetter. Perhaps that mode doesn’t insert the tool change into the file.
It has been a while since I published this article. So, I finally found out what the issue was. It was not the Shapeoko. I noticed on another of my machines issues. I am not going to go into detail, but what solved my issues for everything was to install a power conditioner in my garage and use that source to power all my CNCs. No issues since then. I waited 3 months to make sure I did not see any issues. I also had on a rotating basis each CNC plugged into house power until they had an issue. In over 3 months no issues for all CNCc plugged into the conditioned power.
With that fixed, I re-coded the Shapeoko post processor in Aspire and now with BitSetter and BitRunner I can create one cutting file using all the bits. I can now use the system as designed by the great folks at Carbide3D.
This was a messy issue. I don’t think I would have ever figured it out if I had only the Shapeoko. I hope this lets folks know that good clean power is necessary when running a micro controller.
Noob here. I am having issues the the bit setter as well, at least i think? I am using the Carbide Touch Probe to set x,y,z and I have V1 Bitsetter and am following all the prompts for tool changes and the machine goes to the Bitsetter each time. About every 3rd or so project, after the Bitsetter is used, the machine plunges about 1/4 inch into the material when making the initial pass. On the most recent occurrence, i ran the operation and it was flawless (advanced v-carve to make an eighth inch deep design) for both the end mill and v bit. I then ran the exact same gcode program and it cut the pockets flawlessly, but when i changed from the 1/8" end mill to a 15 degree v bit (it did go to the bit setter) the first pass plunged well below the ‘floor’ of the pocket created in the first step. I also had this issue while running a program for a juice groove on a cutting board. The first pass was at least a quarter of an inch deep even though i had zero’d x,y,z with an 1/8" end mill and then changed tools as prompted and used the Bitsetter with a 3/4" bowl bit. I have run several other operations with no issues whatsoever, but i have now had this depth issue on a single tool operation, on the first tool of a multi-tool operation, and on the second tool of a multi-tool operation (after the first tool worked fine).
Could you prepare a video which shows this plunge and send it in to support@carbide3d.com along w/ the .c2d file, generated G-Code, step-by-step notes on how you are securing your stock and setting zero relative to it and managing all tool changes?