Grbl: Proofing precision and accuracy
After building the DIY Sherline CNC, I had asked myself the question: “How do I proof the CNC/grbl to make sure that everything machines correctly and to spec?” I posed this question to my friend Machinist Mike, and he quickly responded: “Machine a diamond-circle-square test block!” and awesomely generated a g-code program for me to immediately use.
The diamond-circle-square test block is an old school method to machine a set of known shapes and dimensions to gauge the accuracy and precision of a CNC mill. The diamond gauges how well and straight the CNC tracks diagonal cuts; the circle gauges the circularity of the cuts; and the square gauges the primary axes and perpendicularity. This test also will show the effects from backlash, if your machine is not square, smooth feeds from the surface finishes, among other things. Today there are new and better methods to gauge the accuracy and precision of a CNC machine, as the link shows, but for DIY’ers, the diamond-circle-square test is a plenty robust enough test.
The exact sizes and depths of the shapes do not particularly matter, just as long as the user knows what they are. I would recommend to create a large enough test block that is about as large as the parts you intend to machine. A large shape will tell you if you have problems in a certain area of travel. For me, the Sherline has about a 5″ Y-axis travel and the test block was sized to be about 2″x2″ with shape depths of 0.1″.
Also, Mike had noted that when machining with a mill without rigid anti-backlash ball screws, one should always conventional cut, opposed to climb cut (unless doing a finishing pass.) This is because the cutting forces with a conventional cut always push against the leadscrews in the direction of cutting travel. Where as, with climb cutting, the cutting forces push away from the leadscrews in the direction of cutting, causing the axes motion to rattle between the length of the backlash. This can effect precision and surface finish, as well as prematurely wear your lead screws.
Anyhow, a couple of weekends ago, Machinist Mike and I ran the g-code program with the new changes to my grbl fork. We ensured the Sherline anti-backlash nuts were nice and tight with a backlash of less than 0.001″. (The higher torque of my DIY CNC build allowed me to tighten up the anti-backlash nuts more than I would have with the OEM CNC.) We ran the program without any problems from start to finish.
I’m very happy to report that the surface finishes were excellent, the circularity and perpendicularily were also excellent, and all measured dimensions are within <= 0.001″ of the design dimensions. Meaning that grbl and the DIY Sherline CNC are good to go!
One Hoss Shay 
Great article! Wondering if you could post the gcode you used to do the test? I’d love to run it on the newest shapeoko and see how it pans out.
Thanks Edward! The g-code program was generated to the specifics of my CNC mill, in terms of depth and radial cuts, cutter radius, feedrates, etc. It will not likely work with your ShapeOko router and take it beyond its limits. I would recommend generating your own to the specs of your machine. But, if you’d like, I can still post it for reference.
Also, thanks for doing your blog! It was the original inspiration for me to pick up a mill and convert it to a CNC.
Sonny, can’t seem to find your email address anywhere on the blog, would you mind sending it to me? my first name at ed’s life daily dot commercial will get right to me.
Thanks!
Edward
Hi Sonny, I have been looking for your email too. I am about to port grbl to the stm32 processor. I can do this by hacking away at your code and producing a fork for stm32 only or by refactoring so that the architecture dependent code is isolated. Would you be willing to incorporate such refactoring?
Eric
At the moment, I’m not looking to add support to multiple architectures until things have solidified in the grbl development…. at least with the edge version. I would think that it would become a nightmare quickly having to test for everything everytime there is a minor update. I’m pretty heavy in the code development to add a bunch of new features to grbl and it seems to be coming along pretty quickly now.
Some people have written short scripts to modify the grbl codebase to make it compatible with their non-Arduino systems. They have also been sending me some tidbits on how to help them by making the code more compiler independent and portable. I’ll be glad to incorporate those for now.
Probably the best way to get in contact with me is through github’s messaging. I’m under the username chamnit.
Sonny
No problem Since I last posted I have already managed to get some motion control happening on the stm32. I suppose I will just have to track any bug fixes you include.
you will need to move onto either ballscrew or planetary roller screw…
leadscrew will wearout and cause backlash fast.
at first it may be accurate, but soon it won’t be…
Not necessarily. As long as the lead screw nut is made of a material softer than the leadscrew, the nut will wear before the leadscrew will. This is why most thread-based leadscrews are made with steel while the nuts are brass. Brass is not nearly as hard as steel.
Eventually I will need to adjust the preload on the brass nut as it wears, but it still takes a while before I need to do this, especially if things are well lubricated.
The cost difference between a ball bearing based leadscrew and a brass nut lead screw are huge. For small machines or low load CNCs like lasercutters, preloaded brass nuts are fine. For larger CNC and larger reaction forces, things begin to tilt toward ball bearings.
Hi, first, ty for grbl. Works very fine. I use it on a laser engraver.
Comments on stepping.
You use timer1 to set step pins and in ver 0.8 timer2 to reset them. In ver 0.9 you use timer0 to reset pins. There is a way easier solution, use timer1 compare interrupt B (TIMER1_COMPB_vect). Same IR routine as before, but attached t another source. The ‘ON’ time is defined by OCR1B = step_pulse_time;
Works, is simple, and doesent break arduino millis(); or delay();
Not quite that simple. First Grbl doesn’t use any Arduino source code so millis() nor delay() are used. Grbl has its own versions of these. Second, timer1 has a variable timing and prescaler. This make it difficult to constantly adjust and compute the compb interrupt value and set it per pulse. Using a separate timer that deals with the step pulse trailing edge works, is much simpler, and is overall easier to implement.
The fanless PC (running EMC2) that I’ve been using to move the four axes on my Sherline 2010 finally died. I’m exploring smaller and less costly alternatives. Right now, it seems four DRV8834 drivers combined with the Arduino CNC Shield (V3.10) are my best bet for running the CNC’s four existing steppers.
What’s not clear to me, is how well (or not) GRBL works with a 4th axis (e.g. rotary table, same stepper model as XYZ axes). Are you controlling a 4th axis with GRBL?
At the moment, Grbl is strictly 3-axis, but a 4th-axis version is in the works. I plan on releasing this by the end of this year. It’ll run on a Arduino Mega2560, rather than the Arduino Uno since the Uno has run out of flash space and memory for significant additions. FWIW, adding a 4th-axis to Grbl is trivial and there are a couple of forks of Grbl with this installed already.
It sounds like the limiting factor is hardware, and not Grbl, thanks greatly for clarifying. It doesn’t appear that Protoneer’s CNC shield is readily compatible with a Mega2560, what shield would you consider for supporting a 4th axis?
Yes, hardware is the limiting factor for Grbl. It’s very stable and has been written to be easily expandable. It has been restrictive up to now to concentrate on the robustness of the system and completing the last critical features to be installed, which mainly includes real-time overrides.
Not sure if there are 4th axis-ready shields out there at the moment. I would imagine most users will use a standard 3-axis shield and add a stepper driver for the 4th axis, which is easy to do with modern stepper ICs. Just wire in the stepper enable, direction, and step pulse pins and you should be good to go.
I just build a DVD-drive based laser cutter with 30mm axes at 75 steps/mm and 110 steps/mm. I use grbl on an arduino uno. Even if having 8 arcs for a 1.5mm circle they show systematic distortions far beyond the machine backlash. Based on your experience, can you rule out grbl precision problems or is it conceivable that with that low axis step resolution and that small shapes grbl curve tessellation runs into numeric stability problems?
There are no known issues with the arc generation algorithm in the current master release. It’s usually an issue with incorrect acceleration settings.
Ok, thanks. So to your knowledge there are no grbl precision limits resulting in numeric error larger that a step? Then I will try other acceleration settings and perform more systematic tests. Do you have (know of) pictures of millimeter-range calibration laser-cuts that I could use as gold-standard for how precise perfect results should look like?
No. At least for realistic and common applications. Typically one step is less than 0.0001-0.0002″ so if you are incrementing motions less than that, then you need to generate gcode with longer line motions. 0.0001″ accuracy is difficult to achieve in most cases. Otherwise Grbl should ignore any motions less than a step. You can always test an arc converted to G1 lines to prove whether or not the arc generation code is doing something wrong.
I continued calibration experiments using only linear motion. For lines with a certain angle-range it shows a tiny bend and a wavy error. It looks like a random mix of a vibration and aliasing but it is extremely reproducible in its exact shape. However, after varying acceleration, speed, stepper-driver, stepper wiring, sub-stepping, motor currents and switching axes I could pretty much rule out software as the source of the problem. Thanks alot.