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?
Pulley set screws: Checking Pulley Set Screws - Carbide 3D — be sure to check all axes/pulleys (including Z on machines w/ belt-drive Z-axis, for an HDZ, check both coupler screws).
Belt tension (see the relevant step in your instruction manual, e.g., Step 5 Belting - Carbide 3D) Note that the X-axis motor is held in place on standoffs and if those bolts are loose this can cause belt tension issues. Also, belt tension for the Y-axis stepper motors needs to be even/equivalent on each side — a significant difference can cause skipping on one side eventually resulting in lost steps on both. Measuring belt tension, squaring and calibration
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.
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.
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.