Confusing BitZero Issues - revisited

Thanks, Will, but I’m very aware of this possibility, and make every effort not to choose the wrong option.

I confess to having done this once, but realised before probing, so just cancelled it and started again.

Good thought, though.

1 Like

Is 12.53mm the thickness of that material and “Z” 0 would be at the stock bottom/table surface?
I do not have a bitsetter, but could it be that in this instance you had the “Z” zero set as the bottom/table surface?

edit, n/m
I downloaded your file and see that the Z zero is set at the “Top” on 1.00" stock…as it should be


I appreciate all the help and guidance offered by everyone for this very frustrating, random event, that I can’t seem to get to the bottom of, but I’m also worried things may be going ‘off track’ a little, so I’m going to summarise everything as best I can, with what I know as fact, with a conclusion that may be considered controversial.

Things I know:

  1. The XXL is flat, square and level, and has a 25mm MDF waste board installed on top of the baseboard.
  2. The spindle (a Makita) is vertical.
  3. All the nuts, bolts pulleys and wheels are tight, the belts are reasonably tensioned and the machine moves in all directions without issue.
  4. A BitRunner, BitSetter and a BitZero v2 are installed, but everything else is ‘as provided’.
  5. I’m currently using Carbide Create Build 530, Built on: 2021-06-01 on my Mac and Carbide Motion Build 536 (I’ll upgrade to 537) on my Windows PC. Both devices use a shared folder on a NAS to share files.
  6. The routine from starting the machine to running the project is correct.
  7. Connecting to, initialising and homing the spindle works as designed with or without the BitSetter enabled, but under normal circumstances the BitSetter is enabled.
  8. The BitZero v2 works as expected when zeroing to the corner of the stock, parking itself at X=10, Y=10 and Z=19 when completed, and before starting a project. I would always use a probe to do this, not a cutter.
  9. After loading the .nc file and pressing Run, the spindle moves to front and centre, prompts for a new cutter, completes the BitSetter routine, and returns to front and centre to start the project.
  10. When it’s at front and centre, the BitRunner starts the spindle, (although CM prompts the user to start the spindle), prompts to set the speed, then goes off to start the project.
  11. It will start the cut at the correct X and Y axes, but this is when the Z starts at the correct height or cuts too deep. It does not ‘change’ the Z height mid-cut.
  12. The cutter (and the probe) are held securely and do not move.

As all mechanical parts appear to be sound and the steps from starting the machine to running the project are considered to be correct, then either the BitSetter is mechanically changing the Z zero set by the BitZero, or there is a flaw in the software causing that effect, but it is not user error.

Therefore, would you (@robgrz, @Jorge, @Julien, @WillAdams, et al) please consider the user might not be at fault and the issue might be with the software at your end?

Thank you all!

1 Like

Hi Peter,

Believe it or not, I don’t think anyone has any vested interest in defending CM at all cost, there have been many instances in the past when someone came up with evidence of a CM bug, and it was acknowledged and fixed. The random aspect of the failure makes it both irritating for you and almost impossible for any developer to investigate (where would they start ?). What we have established is that something is different in your setup/workflow/project/hardware, producing this random problem when most other folks do not see it (you would argue that several people have reported similar issues, but most of those long threads ended up being user errors, which is not the case here)

I like treasure hunts, so I’ll actually be happy and relieved if in the end we do find a CM bug. But for that, we will need to dig deeper and, I’m afraid, you will need document those failure cases in excruciating details, including tool stickout at each step as I mentioned in my previous post. Or identify a repeatable way to make the BitSetter fail, but I don’t believe this will happen.

The BitSetter does alter the Z zero reference set by the BitZero, always, on purpose. We “just” need to understand why it does it with a wrong offset/compensation value, apparently randomly.

Does your BitSetter “stick” when you push it manually ? It could be interesting to probe the same tool repeatedly, and check (in the logs) what Z value it triggered at, to detect whether from time to time it comes up with an outlier value for any reason. By the way I lost track of whether you have interacted with support on this problem and where things ended up with them ?


Well, it now occurs to me that you should either change versions of CM or change to another sender.

That’s the only way you’ll eliminate the software possibility.


Yes, we’re perfectly willing to accept that their are bugs in our software — we’ve fixed a lot of them, and we usually do so based on bug reports which are repeatable at our end.

From: FAQ - ShapeOko

To eliminate the software, please check it in a 3rd party previewer — list at: Previewing G-Code - ShapeOko

Verify that you are using up-to-date software versions including the firmware (Grbl 0.9 originally, currently 1.1 and that the versions match, Carbide Motion 3 with Grbl 0.9, CM4 or later with Grbl 1.1).

Review that the machine is properly assembled according to the assembly instructions and that everything checks out per the Machine Operating Checklist: Machine Operating Checklist - Carbide 3D

The software works by:

  • Carbide Create (or some other CAD tool) creating geometry
  • assigning toolpaths to the geometry
  • exporting toolpaths to .nc (G-Code) files (using the appropriate post processor, Carbide 3D Shapeoko for Carbide Create)
  • Carbide Motion connecting to the machine (and if need be sending the correct settings for both the machine and Grbl)
  • initializing (homing) it
  • moving the machine to the correct origin relative to the stock and setting zero there
  • sending the G-Code file
  • appropriately changing tools as prompted

    ​The machine is able to move based on:
  • the controller interpreting the G-Code to make
  • impulses from the stepper driver — usually if they don’t work right there are horrible noises
  • sent through the wiring — check the connections and wiring — if you or a friend have a multimeter use it to check for continuity
  • received by the stepper motor — these almost never go bad
  • which rotates the motor shaft — check that this is true and not bent
  • which rotates the pulley — check that it has two set screws at least one of which is on flats and that they are secure: Checking Pulley Set Screws - Carbide 3D
  • which pushes/pulls on the belt (or screw) — make sure that the belts track true through both the pulleys and the idlers and are in good condition, secure at appropriate points and well tensioned (see the assembly instructions)
  • which moves the machine along the V rails guided by V wheels (or linear rails for a Pro) — make sure that the latter are properly adjusted Tightening Eccentric Nuts - Carbide 3D and the former clean and in good shape, lubricate rails as necessary

The machine then cuts based on:

  • the trim router being securely in place
  • having an endmill properly installed in a clean and well-fitting collet properly tightened
  • being moved along by the toolpaths without running off the rails and running into a limit of motion along any axis or any workholding or physical obstruction such as a cord, dust collection, &c.
  • which matches the toolpaths in the G-Code (which brings us full circle)

For electronic accessories, check the connectors and the wiring along the entire length and that they are properly configured and enabled.

To extend on the above, we need to work up some technique for verifying the functionality of the BitZero and BitSetter.

For the former, it should be a straightforward matter of after probing, use the jog controls to move the machine around to verify that the origin was set as desired relative to the stock.

The latter can be a bit trickier, since if one is running tool changes in a G-Code file, the machine still has control — please try breaking up a test file such as:

and export each tool separately, then do a tool change in-between each file.

Let us know what you find out and we’ll do our best to sort things out.

To review, the expectations are:

  • the machine is powered up and initialized w/ a tool or probing pin loaded
  • the origin is set relative to the stock, either by hand or using a BitZero, probing once (at lower left corner) or multiple times
  • (optional) the tool change interface is used to change a tool and the tool length offset is measured
  • a file is loaded, if the correct tool for cutting the first part of the file is not loaded, it is loaded using the interface
  • the file is run, tool changes are managed using the BitSetter

I would suggest breaking things down and testing incrementally:

  • first cut the basic diamond-circle-square calibration file which uses a single tool setting the XY origin by eye at the center, and the Z origin using a bit of paper — if that file cuts well, the machine should be operating correctly mechanically
  • modify the file to put the origin at the lower left corner of a suitably larger piece of stock and set the origin there w/ a single probe operation using the BitZero — if that file cuts well, the BitZer would seem to be operating correctly
  • load a calibration file which requires tool changes but which is broken up into multiple files — use the BitSetter manually after each tool change to change the tool, and verify the Z-origin relative to the stock before each file

Not being picky, but please clarify this. Especially the “always” part… does this mean even (potentially) after the probe and during cutting?
Have you tried running with all the peripherals disconnected?
(fwiw…you may have mentioned this earlier but I missed it)

I meant “systematically upon probing”. It does not interfere later (during the cut), that’s guaranteed by GRBL behavior (which ignores the probe signal input unless explicitly requested, and that happens only during probing through a G38.x command). Technically one could also imagine that CM would erroneously sends a command to change zeroes during a cut (very unlikely if you ask me, but let’s keep an open mind). A dump of the log window would settle the matter.

1 Like

Thanks, Will. I appreciate the sentiment and information provided, but seeing this has set my teeth on edge. Most (I haven’t read it all, but I will) revisits all the points raised over the previous replies, so may not be useful, specifically your reference to using a 3rd party viewer. If it works the first time, why didn’t it the second time, following the same procedures?

As I said, I’ll read what you’ve copied and pasted, but it will take a while.

I believe you, but it’s a struggle when I’m confident I’ve done everything I can to make sure I stick with the guidance - to the point of writing and pinning up a checklist - for it to go wrong at a random moment.

Maybe permanently enabling the log would help - at least temporarily? Maybe an option in Settings to keep it enabled (disabled by default) would be a good idea, then we can keep it that way until a problem occurs. Of course the log for a particular session doesn’t need to be saved after a successful session, but saved manually if the machine ‘misbehaves’ (Which would also obviate any performance issues, as identified by Will).

No it doesn’t, but the BitSetter button did come unscrewed from the mechanism and I had to screw it back in with a drop of thread glue.

Not yet, other than for flattening boards with a fly cutter, which went well. I’m convinced this is an issue between the software, and/or the BitZero, and/or the BitSetter, so when I next run a project, I’ll probably dispense with the BitZero and see how that goes.

My thinking too. I have looked at some other senders, but I want to retain the use of the BitSetter, BitRunner and BitZero (otherwise they would have been be a waste of money), and I haven’t really found something I’m confident to play with, yet.

Please provide a .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 and notes and documentation on how a workflow which should work, results in an incorrect positioning relative to the stock which is repeatable — with that, we can look into this as a problem with the software.

If things aren’t repeatable, then it is likely some electro-mechanical aspect of the machine which is having a problem — we need for you to work with us on support to work with us so we can determine what is causing the problem and how to address it. Send an e-mail to describing the difficulties you are having and we’ll do our best to sort this out with you.

I know you mean well, Will. But this is clearly copy-and-paste text from 100 other support responses you make, and to be honest it sounds a little patronising after two huge threads detailing pretty much all of this. Peter has done some of these things already. We have his c2d, the gocde fine, pictures of his stock, how its secured, what he is doing. (plus, how the stock secured is irrelevant for nearly all of the occasions when you ask for it.)


And when I’ve run his files, I don’t get the results which he notes, so it’s not repeatable, so we need for him to either increase the detail of the information which he is providing so that it is repeatable, or work with us via an e-mail to so that we can determine what is wrong with the machine if it’s not the software and not user error.

I get that. But perhaps those lines from your support template should be tailored for the specific situation. Otherwise, it comes across as robotic and implies you haven’t read the thread, which I know you have.

1 Like

And when I run my files I don’t get an error - until I do. It’s random, @WillAdams, and by definition not repeatable.


1 Like

Please provide a list of all the ways that your files have been out to and we’ll do our best to work out with you how to resolve this.

Peter in your recap above if I read correctly you design on the Mac and run CM on a Windows machine. I know that it may be a stretch since Windows and Mac play well together now that it may be just something in transalation between the two. Have you tried doing both design and running from the Mac and design and running from the PC? I have seen weird things happen cross platform before. Also running all the latest software may get rid of this bug.


I’m not sure of that would cause a random event, but I’ve got my MS Windows machine running in MS Remote Desktop on my Mac, so trying it wouldn’t be a problem.

I’ll give it a go, thank you.

And so the circle closes.

You no longer inspire me, @WillAdams, and my future with Shapeoko is dwindling fast.

1 Like

Please write in to with your suggestion for how this should be researched and resolved.