Random leftwards offset on toolchange?


Our FRC team has gotten a Shapeoko 4 in order to up our fabrication game, and I’m running into a weird issue. We’ve gotten the machine built and surfaced the wasteboard, and done some basic cutting with it successfully. We have a bitzero, bitsetter and bitrunner.

Anyway, as a way to get some experience with the machine, this weekend I decided to make some coasters as gifts for our graduating seniors with our team logo on them. However, I run into a weird problem when I tried to do an advanced vcarve.

Sometimes – but not every time (!!) – after changing from the endmill to the v bit, the v bit’s cut was offset about .1-.3 to the left, and I can’t figure out why that might be happening. After stopping one of the errant runs, I rechecked the zero position, and it seemed to be right where I set it. And it seemed like sometimes I could just restart Carbide Motion, reload the gcode and it would work fine.

Furthermore, after one of these bad runs, I started a new run and the initial bitsetter calibration position was also offset to the left – it completely missed the bitsetter. This was a one-time glitch; other tests that exhibited the v bit offset problem put the tool on the bitsetter normally the next time it was used.

After the bitzero calibration glitch, reinitializing the machine brought everything back to where it should be.

After messing with this for a while, I backed off and just used a contour toolpath with the v-bit to etch the logo outlines into the coasters, and it worked flawlessly, churning out the gifts in short order.

So, two basic questions:

  • What might I have been doing wrong that would cause this issue?
  • If it happens again, what extra information should I attempt to gather in order to properly diagnose it?

Thanks in advance for any insights you can offer.

Usually this sort of thing is mechanical.

Per the machine operating checklist: Machine Operating Checklist - Carbide 3D , the basic points of adjustment for a machine are:

TYVM for the suggestions. I checked all the items you listed and everything appears to be snug. I backed off and retightened the x-axis stepper set-screw just in case that was the issue.

The machine performed flawlessly last night at a team build session, but we did not do any advanced vcarve operations, so I have not been able to explore potential non-mechanical explanations for the anomaly. At this point I will just monitor the machine and update this thread with more details if it happens again.

A remote possibility is that when changing the tool and tightening the VBit you moved the axis slightly. This is hard to do but might be possible if you are only using one spanner, for example.

1 Like

I considered this but judged it unlikely – I always used 2 wrenches and tried to be gentle. And the weird thing was that homing the machine to 0,0 after the anomaly indicated that it was still properly set.

At this point my leading theories are a gcode generation bug, a bug in Carbide Motion, or some sort of transient issue in the controller or the tablet running Motion. When I get some spare time I am going to run some tests and see if I can narrow it down and generate something that reliably replicates the anomaly.

TY again for the suggestions.

1 Like

This is a late response, but what software are you using to generate the toolpaths? In Vectric VCarve, doing an inside or outside cut WITH an offset allowance moves the toolpath so that the edge of the bit continues to contact the vector. This is intuitive with a straight bit, but less so with a V or contour bit; the toolpath changes depending on the depth of cut.

Appreciate the input. We were using Carbide Create/Motion - and so far, the issue has not arisen again - the machine seems to be working nominally.


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