Advance Vcarve fail

I just finished a 2 hr run on my test project. Started with the area pocket tool #102 and wanted to finish with the #301 V-bit. After the Tool 1 run the machine stopped, there was no option or signal to change the tool to the V-bit. So I pressed pause (there was no other logical option), changed the bit and the machine ran the Bitsetter procedure and it didn’t want to resume somehow. I started it again (had no other option as far as I could see) but the machine started again from the beginning. So, what do I have to do to change the bit after the first run and continue the process in a second run with the Vbit?

test2_advvcarve.c2d (45.2 KB)

EDIT: it feels like I somehow have to tell CC also that I have a bitsetter?

In Carbide Create: Edit | Select Post Processor — choose “Carbide 3D Shapeoko”

Make sure Carbide Motion is configured per:


Thanks Will,

CM was configured according to the instructions, CC wasn’t…

I don’t see anything wrong with your tooling setup.
If your Vcarve ran ok, I’d disable that part, save the Gcode and run the cutout as an individual file.

I’ve had to do that from time to time.

Maybe it would have been a good idea to put this also in the instructions, I might have overlooked this part but I can’t find it in the installation documentation. But I’m glad with this info and will do the next testrun today. Spent all night last night to watch all the beginners video’s again so nothing can go wrong anymore! :laughing:

1 Like

Another question about the squence… :grimacing:

  • I start op the CNC, initialize, spindel moves to mid-front and asks me to change the bit.
  • spindel moves to bitsetter, measures to bit and moves back to mid-front
  • I want to jog to use bitzero, machine asks me if I want to measure the bit first
  • I deny and use the bitzero
  • Spindel goes back to the bitsetter ad checks again
  • I run my file…

Is this the right sequence? Does bitzero and bitsetter do the same with the Z axes?

think of it this way:

  • bitzero is used to tell the machine where the surface of the stock is, with one specific tool inserted in the router. As long as you don’t change/adjust the tool, you don’t need a bitsetter (actually, for years the bitsetter did not exist on the Shapeoko, it’s a fairly recent development)
  • bitsetter is used to figure out the difference in where the tip of the tool is, between the initial zeroing and the moment when you later insert another tool. Before, when changing tools, we had to redo the Z zero manually, and run a separate gcode file. Now with the bitsetter, you can run a single gcode file that has toolpaths for different tools, and the main point is that you don’t have to re-zero, the bitsetter takes care of automatically adjusting the real Z zero based on the initial Z zero, and the measure of the tool length difference.

The sequence you mention is fine, just remember the ONE golden rule for the bitsetter: never, ever swap the tool without being prompted by CM or explicitly using the change tool button in CM. If you swap the tool “behind CM’s back”, bad things will happen.


It becomes a bit annoying now. Again, half way in the job the machine plunges in the wood again, the bit is firmly set in the spindle so it can’t be that. The spindle goes up and down and I’m getting an error message now. Not happy (to put it mildly) ← VIDEO

test3.c2d (45.2 KB)

Please check the Z-axis motor wiring and connectors — if you don’t find anything obvious to address, let us know at (send us photos of the wiring connectors in question).

I checked all wiring but it all looks ok, no wrong connections. When I would have a wrong connection it should fail all the time. Right now it is totally at random. I don’t know where else to look. I will make some more pictures and send it to support. I don’t want to go back to Easel because I want to use CC/CM but with Easel I never had these problems so I personally don’t think this is hardware-related (but again, I’m no expert). It’s all very disappointing. I’ll send support an email right away.

Honestly, looking at that video it does seem like a likely cause though, sometimes it all looks ok visually but somewhere inside the cable there is a poor connection or half-break somewhere, which makes it random by nature (the connection makes and breaks at each tiny movement of the wire)

If you jog the machine up and down in the air and wiggle the cables while you do it, do the jittery movement come and go randomly ? If so, that would definitely point to a wiring quality problem.

There is no way that G-code alone (CC/CM) can produce random/jittery movements. If you send that specific video to support, I think a cable swap will be the logical next step to fix this for you

It looks like you are right Julien, when I wiggle the wires it does have an effect of the Z axes sometimes. I will write support and ask them to send me some new wires… Thanks!

1 Like

It’s been a few weeks but I’m back in business. Many thanks to @Julien for thinking along and especially to @WillAdams and Brandon Lee for their support. C3d has sent me some replacement parts and I just finished 2 test projects. The last one was the project where things went wrong for me the other day. I used the same file again. This time everything just worked perfectly, including bit changes halfway in the cutting process with my new Bitsetter v2. Needless to say, I’m extremely happy with the fact that everything is working great again and impressed with the C3D support. Thanks guys!


This topic was automatically closed after 30 days. New replies are no longer allowed.