X/Y belt stretch mapping + dynamic compensation in GRBL


Last time I calibrated my $100/$101 values, I went blue in the face trying to figure out correct average values that would work across the work area and for various dimensions of the cut, and found out the hard way that it is quite difficult to find a “perfect” pair of values (I should have read the multiple posts from @RichCournoyer on this, stating that the effort is pretty much hopeless and one might as well do a test cut and scale the CAD based on the measured results). I ended up leaving the calibration factors alone, and indeed adjusting tolerances here and there while designing.

The inner geek in me has been thinking about correcting the small non-linearities of the movements on the X and Y axis by first mapping them across the work area and then having GRBL compensate for them dynamically. A map of $100/$101 calibration factors depending of x and y position, if you will. Kinda like the basic “bed leveling” function of 3D printers, where a sensor comes and probes the surface across a large 2D area, and Marlin firmware then has this matrix of correction coefficients that it applies to correct the tilting of the surface.

Has anyone entertained a similar idea ? It’s probably not worth the effort (i.e. many people get extremely good precision without resorting to this), but imagine if we had a fully automatic belt stretch compensation/calibration procedure based on one test cut, wouldn’t that be nice ?

Does the Shapeoko use the vanilla GRBL 1.1 source code publicly available ?



Yes, we use Grbl 1.1 (and fund its developments) and you should see comments in the header files which indicate the defaults for the version which we compile and install.

It’s a great idea — the problem is working up the data — I’ve opined in other threads that the next two big things for CNC at the hobbyist level will be positional encoding and a 4th axis.

Just to be clear because I think this gets lost on newbies quite a bit.

We CAN calibrate for belt stretch and pulley variances by taking measurements over the entire distance (or as much as possible) of travel of an axis. Typically I find these variances to be multiples of what I’d measure at short increments.

At this time, not much can be done about variances in pulleys and belts over shorter distances. That is the solution you’re discussing. Of course, your particular solution to the micro issue would fix the macro issue, as well.

One of my clients (I do IT) is a machining shop that does very high-end work, and I know they have resorted to mapping nearly everything to achieve the precision necessary for some jobs. They do work for auto makers and all sorts of places so when they showed me one of the jobs that required the greatest degree of precision, I was surprised to see it was…a large valve (of all things). That thing drove them to pull their hair out, though.

From my perspective, this sort of precision only makes sense once you’re using servos (so you know you aren’t losing steps). Or if you could use some sort of feedback loop that would be an input to drive the steppers.

Otherwise even if you map everything, I feel you’d still run the risk of blowing everything if a motor stalls for a step or two.

And honestly, the small variances in the belts and pulleys are honestly better than what I ever got with the K2 (Acme screws). Probably too many people draw something, cut it, measure it, and think the variance is the belts and pulleys, when it is often more likely deflection.

And then there are people that struggle to measure accurately. Heck, I visit another forum where a member was cussing his new sliding miter saw’s inability to cut square on both sides of the blade. He talked about how picky he was. In the final analysis, his square, wasn’t.

That was a lot of rambling, no? What do I win?


Thanks Will, I realized that after browsing the GRBL source code a bit and seeing the “Shapeoko3” sections (and @robgrz and @edwardrford names in the contributors list :slight_smile: ). That is excellent news in itself for me, meaning I can safely put my dirty hands in the GRBL code, and still be able to reflash the vanilla firmware if I break something

All very good points, thank you. I agree it is much harder than it looks to measure right, and even harder to figure out the actual source of the dimensional inaccuracies. So my intention was to not even try understanding where the inaccuracies comes from, just compensate them (a.k.a. the “3D printer approach”). Now Will and you have opened my eyes to the fact that probably this endeavour would require to investigate ways to hack an encoder on each axis. Next thing I know I’ll be ordering a superGerbil to manage it all, and go down a 1 year rabbit hole.

I am aware that I really do not need that kind of precision, honestly I am mainly looking for an interesting/motivating usecase (i.e. excuse) to dive into the GRBL code and roll my own firmware :slight_smile:

@Julien What exactly would you be trying to automate? Marlin’s bed leveling probes the build surface, creates a nap and adjusts motion based on that. Something similar can be done with grbl based machines using a Z probe and a UI capable of it.
There are also printers with skip correction but that involves a hardware change as well.
What would you be measuring/adjusting that could be added to GRBL’s source code?

Edit: As I was typing, you added your last reply which mentioned the addition of encoders. Even then, you’re only able to measure shaft rotation, only one of the several possible causes of loss of accuracy.

1 Like

In my (probably somewhat naive) original idea, I was not aiming for the perfect compensation of all possible causes, but doing something like this:

  • perform a test cut of a predefined pattern, probably a grid of many pockets of various sizes and placed at various locations covering the whole X/Y work area
  • I would ignore the Z axis for now, since I now have the HDZ. It may have inaccuracies of its own, but belt stretch will not be one of them…
  • manually measure the actual dimensions of each pocket (tedious, compared to an automatic probing, but doable), and fill a table of coefficients in the GRBL code, i.e. a lot of “local $100/$101 values” for each area)
  • in the piece of GRBL code that uses the $100/$101 coefficients to translate a distance to a number of steps, take the current X and Y position (from home), and use the closest pair of coefficients from the table (or go nuts and interpolate between neighbouring reference points)
  • possibly complexify the scheme by also having a table of coefficients for different lengths of movement from a given position (as a very long straight cut may not behave the same as a lot of small ones)

But mostly this was just a wild idea and me wondering if it made sense, and if someone had done something similar, before I reinvent the wheel.


I say add some lasers to constantly measure the location of the endmill and have the controller handle the error correction in real time.

Seriously though, keep the community updated on what you try.


The supergrbl folks are making some changes, like adding additional axes, but I haven’t seen their code yet.

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