GRBL-driven router, undersized pockets

[kfmut]

Hi,

I've stuck with calibration of my GRBL-driven CNC router It's was built around OpenBuilds linear rails and has plain simple stepper motors and GT2 belts on x/y axis. I've calculated steps per mm on both axis with caliper and mechanical edge finder on 120mm base(distance between caliper jaws), repetition accuracy on that base was about 0.05mm.

For accuracy check simple part was drawn, it's outer dimensions 70x70mm, circle has 45mm diameter, inner pocket is 30x30mm, plus few holes ranging from 6mm to 12mm. I've checked milled from plexiglass part with same caliper and it has all outside dimensions smaller by 0.1mm(which seems OK for that style of linear rails) BUT all holes and central pocket is undersized by 0.3mm. I've ran G-code for pocket and holes few times with intention to eliminate influence of low stiffness of aluminium profile and overall construction, but in all subsequent runs barely any material was cut. I just couldn't understand why all inside dimensions has three times bigger accuracy error Any ideas?

If it matters G-code was generated in Fusion360 and streamed to Arduino through bCNC.

PS I've also checked numbers in generated G-code, toolpath looks accurate, without any unwelcome compensation.

Similar Threads:

• Newbie- Brainstorming, using an Arduino GRBL kit from eBay for a router build
• Need Help!- any one that knows Audrino and grbl shield with grbl pannel?....
• Problem- Alibre CAD/CAM Undersized pockets.
• Is 12mm/2mm ballscrew for Z-zixs router undersized?

[Biggs427]

This is not and Arduino related problem.

Are you certain that the cutter diameter is what is advertised? I have a Freud cutter that is sold as a 1/4 cutter (6.35mm) but I measured it and the diameter is 6.06mm.

Have you measured the backlash of you r machine?

Do you machine conventional or climb?

[kfmut]

Are you certain that the cutter diameter is what is advertised? I have a Freud cutter that is sold as a 1/4 cutter (6.35mm) but I measured it and the diameter is 6.06mm.

Have you measured the backlash of you r machine?

I think if my problem is related to cutter diameter or backlash or whatever which is measurments related it will be same for outer contours as well, but they are good as could be :-) But I will measure cutter OD with micrometer, thank you for your advice!

Do you machine conventional or climb?

Conventiontal.

I've tried to increase cutter engagement up to 30% of its diameter on final passes to insure that it's really cutting and not rubbing vertical wall and deflecting but without any luck.

[kfmut]

Per specs cutter is 1/8inch(3.175mm), my measurment is something like 3.165

[Biggs427]

Try the same tool path but with climb cutting and measure.

Are the circles real circles? Not oval?

Maybe try another program to make certain it has nothing to do with the CAM.

Maybe program it by hand; that way you would sort out any CAM problem.

[kfmut]

Try the same tool path but with climb cutting and measure.

No luck here. It's exactly same error of 0.3mm. Three runs with different feeed and speeds, original toolpath was bit aggressive which resulted in chatter so I was forced to lower stepover and feed. Also switched between bit with spiral flutes and straight, no difference.

Are the circles real circles? Not oval?

Nope, dimensions in X and Y directions are same.

Maybe try another program to make certain it has nothing to do with the CAM.

Maybe program it by hand; that way you would sort out any CAM problem.

I've checked program by eye and by generating stl-model with CAMotics and taking measurments from this model, it's looks OK to me.

I was thinking about trying another CAM but looks like there not so many decent options which are free to use, any recommendations? Also checked alternatives for GRBL and found that some missing arc support, some not working on atmega328 chip, etc. One real alternative is to install MachineKit on RPI but didn't found step-by-step instructions howto tune it after installation for working with GPIO.

[Biggs427]

Pretty certain that it is not GRBL related.

I don't know CAMotics, but in Fusion 360, there's a "Stock to leave" option and it is checked by default.

If you code a simple 100mm x 100mm square by hand, this would elimitate the CAM from the equation.

If you do a 150 x 150 square, do you have the same margin? If so, it looks like a compensation problem to me. If the error scale with the size of the pocket, it is more likely a mechanical or a step / mm problem.

[kfmut]

CAMotics is simulation for 3-axis mill, it could generate facet model by running g-code in virtual stock, result could be saved in stl-file and measured in any mesh editor.

CAMotics site.

[kfmut]

Just in case if someone would run in similar problem I leave my note for the History


I've checked spindle's RPM and it was much lower than I expected, all calculated feeds and speeds were way optimistic, like in two times , and thats why all minor tweaks in WOC, DOC and chipload didn't gave any results, chipload was always too high.


I've also dumped Openbuilds flimsy delrin wheels in favor of chinese copy of Hiwin MG rail system on router's gantry, and it gave quite large boost in performance, something like 20-30% to material removal rate.