I intended to post some progress notes on this thread, but it has been closed due to a month of inactivity. I got sidetracked learning how to cut aluminium to make small adapters for this calibration jig I had in mind, which itself led to learning Fusion360, so there I am, back on my original track 1.5month later
Anyway, here is the start of prototype #0. I assembled a DRO scale onto a set of rails:
The idea will be to move the router to predefined positions across the work area, and compare them to the actual positions as read by the DRO. Of course prototype #0 only has one axis, but the endgame would be to do this for two axis, and use this collected data to build a map of calibration factors ($100/$101) across the work area
I already have the digital readout part covered, here’s a concept using a sacrificial cheap-o-caliper and an arduino:
I am quite aware that I may end up mapping the inaccuracies of my mechanical jig instead of the inaccuracies of the shapeoko/belts, and that this is all a bit pointless (since a “normally calibrated” machine can achieve surprisingly good precision already), but for some reason I’m having fun pursuing this endeavor, and it forces me to get out of my comfort zone and learn new things (e.g. cutting Aluminium was one)
Follow-up: I soldered the wires onto the DRO scale, hooked up the arduino, wrote a small arduino program to grab the current position, and wrote a small Python script to generate a G-code file that moves over a NxN position grid inside the 30cm x 30cm workable area.
Here’s a short (boring) video of it moving/acquiring data using a 7x7 sample grid
which got me a matrix of actual positions reached, and then a map of the relative errors (unit = 1/100th of mm in the colourful part):
So basically between -0.3mm and +0.5mm error. Which is way more than the intrinsic precision that I know my machine has (I recently cut a piece within 0.05mm of its expected dimension), so there you go, I’m looking at the mechanical error of my jig (which is not surprising, this quick and dirty prototype was aligned/assembled by hand, is probably not quite square, and has some play where the router joins the DRO (I used an old/worthless chinesium V-bit to center the router into one hole of the metal plate attached to the DRO display…)
So next steps: a better mechanical setup, and a custom made piece for attaching a 6mm stud to the DRO with no play. Then repeatability tests, and manual/calibrated checks to map the error of the jig, before mapping the errors of the Shapeoko.
I read somewhere that for good results, the accuracy of a measuring instrument has to be an order of magnitude better than the accuracy you are trying to measure. Can you realistically make something so precise?
Prototype #0.1 got me closer to where I want to be:
I disassembled everything, used Fusion360 to make a sketch to drill 4 holes at the four corners of a 40cmx38cm rectangle, then fastened the jig’s MDF base onto the wasteboard, ran the job, and re-assembled the rails using this 4 holes. This is obviously much better than fastening a pre-assembled jig onto the wasteboard, because now it’s the shapeoko that decides where the four corners of the setup are, so this guarantees that the X/Y axis of my jig are perfectly aligned with the X/Y axis of the machine (which may or may not be 100% square, depending on how good a job I did at squaring)
I found a better way to attach the DRO and router. I rumaged through my box of Ikea random parts, found this piece that happens to have an 8mm shaft (after sanding off the paint that is), used the 8mm adapter that came with the Makita, and used two nuts to fasten the DRO to this shaft
What I find interesting that I can clearly see the raster pattern reflecting in the data, AND the error follows the same trend whether moving from left to right or right to left. I doubt this comes from the DRO itself especially following the manual tests showing that it’s spot on within 1 unit (0.01mm), so I tend to think that what I am seeing here is the effect of the belts:
when starting on the left side and asking for a 50mm move to the right, the gantry/stepper “pulls” on about 40cm of belt, which I imagine could present the max amount of stretch
when starting from a position that is near the right side, the stepper pulls on just a few cm of belts, which I imagine could have a lower amount of stretch
same story in the other direction for the returning zag moves back to the left side.
Also, the average value across all 48 moves is 49,96mm for a target of 50mm, so this tells me my $100 current calibration factor is not bad at all (and that I should not bother with tuning further, but I already knew that)
Since this is from a single set of data, I’ll repeat the test to have something statistically relevant (which is the whole point, I always wanted to have this fully automated eventually, let it run for a few hours, acquire hundreds of samples across the work area, and THEN I might get rid of the measurement noise and have enough precision to get useful mapping data)
To start to answer your second question, here’s a new run (just returning to zero and replaying the toolpath):
The pattern is definitely still there, and the delta between this measurement and the previous one (bottom table) shows that repeatability is somewhere in the 0.02mm ballpark (standard deviation of these delta values is around 2, if discarding the -16 that looks like an outlier)
More tests to follow to get more runs, and answer your first question (longer moves)
EDIT: here’s one more run, which confirms the repeatability is very decent:
the delta is compared to the previous run, since I may have re-zeroed between #1 and #2.
I am also quite amazed that returning in a straight line from the back right corner to the front left, leaves me repeatedly within 0.02mm of the original zero.
Interesting, I did not know about this book (unsurprisingly, since I am not a mechanically-inclined person, having spent most of my career messing with 1’s and 0’s). I’m sure the gods of accuracy would laugh at my experiment in any case.
Yeah, there are times that I really worry about the nature of human knowledge and how it’s stored, and how it’s disseminated.
I really wish that IBM was doing more to publish their dataset for their Watson expert rule system, and that things such as Wolfram Alpha were more accessible, and more useful (I was really disappointed when I tried to use Alpha for some machining calculations a while back).
Interesting all that can be summed up in a disagreement back at the beginning of the World Wide Web — Tim Berners-Lee’s objection to terming “URL” as “Universal Resource Locator” — his objection resulted in it being termed “Uniform Resource Locator”, which while it makes sense, justifies the inconsistency of information location, and created the need for search engines, as opposed to an idealized directory structure.
A well, Xanadu never could have worked out, and if it had, folks would be crying monopoly.
An interesting corollary to the identity of “The Last Man to Know Everything” (I’ll leave it to the reader to decide if that was Enrico Fermi or Andrew Young) is what is the smallest current subset of published books which contain the greatest quantity of human knowledge. I actually got started on putting together a list of Abbé Faria’s books:
(from The Count of Monte Cristo)
but I wonder what an equivalent collection for the realities of the modern world would be.
Heinlein touched on this sort of thing a bit in his Space Cadet and I’ve always wondered what modern education would have become without the electoral credit system put forward by Charles William Eliot of Harvard (to which awareness of I have to credit Roger Zelazny’s wonderful novel Doorways in the Sand)
and to answer your first question, in fact I already did this test: I did repeated moves of the full width of my setup (300mm); back and forth, and results were like this:
(and I am not making these up…!)
at some other Y offset I got:
at which point I stopped since it was getting boringly repeatable
To me it is not surprising that repeatability is better by doing one long move than several small ones (where errors accumulate each time the gantry stops/restarts)
Didn’t mean to derail things, I just find the very idea of knowledge fascinating (though I found even Kant’s Prolegomena impenetrable) — curious if you’ve come across Ted Nelson and EDIT: Project Xanadu though.
No problem, keep the book recommandations coming ! I’m just humbled by your references, I’m not much of a reader beyond binge-reading all the Pratchett’s and King’s in existence, so totally different league
On a more down to earth note, I found the reason for all the outliers values (in red in the colourtful tables above): this is purely a mechanical problem with my setup. When I position the DRO at one end of the scale, and perform a move away from that side, the OTHER end of the scale rotates ever so slightly, but noticeably. The scale is being “forced” to a straighter angle, and then for all subsequent movements, no deviations is noticeable, so values are back to their good/much more precise values.
Conclusions of the day:
I need a better setup (no wonder)
the “center” part of the data is probably correct, in which case:
standard devision = 2 = 0.02mm
mean = 5009 = 50.09mm, so my $100 should be reduced a tiny bit, after all.
but still that would indicate that the same command to move 50mm, actually moves between 50.05 and 50.15mm depending on where on the work area the gantry initially was. I’m ready to continue this little game, if mapping & compensating for this effect, gets rid of 0.1mm (0.004") variance, it may be worth it.
My wife and kids are big Pratchett fans — I unfortunately, got burned out by Piers Anthony when I was young (read all the Xanth books then in existence one summer), so have a low threshold for humorous fantasy — still loved Barry Hughart’s Bridge of Birds though, and am delighted that apparently the author’s foreword to the omnibus edition: The Chronicles of Master Li and Number Ten Ox is the description on Amazon:
Apologies to readers for making incremental updates/posts like that, but I could not resist tuning my $100 factor based on all the data above in the center part of the work area (say the 20x20cm area in the center), and re-running the test, discarding the extreme right and left values, and I got this now:
NOW we’re talking.
Average is 4999.5 for a target of 5000, so my $100 factor cannot get any better, but interestingly the standard deviation is still around 1.7 on this data, so 0.017mm. Very close to the 0.02 stddev I had with my previous $100 factor.
So this confirms that I see a ~0.02mm variation depending on where on the work area the movement starts, with a max delta of 0.07mm => here’s my 0.1mm variation to get rid of again.
Yes, it could still be the calibration setup that induces it though. And yes, it many cases the endmill deflection will be larger than that.
And finally, this confirms that compensating for this effect at runtime is unrealistic: the min I see is 4995, that would mean applying a correction of 5000/4995 = 1.001
I’m pretty sure that the limited precision in computations in GRBL/the arduino controller, would round the corrections into oblivion. What may still make sense, is an offline pre-processing of the G-code file. That’s my next move I guess
That off-line pre-processing is what we recommend for folks who want the ultimate in precision (and in my understanding is what @RichCournoyer does for his work) — simplest technique I suggested was to cut a part, measure it, then adjust the measurements of the cutting of a copy to achieve the desired dimensions.