Currently I'm trying to improve the accuracy of the probing of my cnc machine running on the grbl firmware. In order to do this I want to implement backlash compensation using software since I'm streaming the Gcode to the controller by using Pyserial. However, I'm pretty sure that grbl does not offer backlash compensation with built-in features. My solution to this was to try to detect when the machine changes directions for a certain axis and then let the machine move by the backlash distance first and only then resuming with the next command. During the backlash compensation move I would like the machine coordinate system not to change since this is what the probing commands use as a reference. However, I have not figured out how to do this yet. Any suggestions would be very welcome.
To do this with 8-bit grbl, you'd have to write a post-processor (even a stand-alone command line one) to parse the code and at every direction change insert a line of code to take up the lash and another line (G10 L20 P1 or whatever) to reset the work coordinates to what they're supposed to be. Not even bCNC has a backlash comp method built in, and no one's gonna bother at this point with an official 32-bit grbl coming out before too much longer (it's already in the xPRO V5). They'll wait and see what that brings first. Realistically it's a choice between grblHAL or LinuxCNC if you need to move to backlash comp in the short term. grblHAL requires 32-bit hardware like a Teensy 4.1, and if you look at the git you can find backlash comp references. LinuxCNC of course requires a Linux-capable machine with a parallel port at a minimum, usually a full PC, but then your sender and controller is in a single device. That can cost some money to optimize performance though.
Hahaha that was gonna be my third paragraph but then I completely forgot about it. Even with comp, getting physical lash as low as possible is important. If it's lead screw, that's easy. If it's ball screw, that's trickier, but not impossible.
Thanks for all the replies! While I agree that fixing the mechanics would be best, I would like to see if a software based solution could work as well. I did some further research and I believe that it is only possible to get the probing coordinates in the machine coordinate system. Since these are fixed, changing the coordinate system turns out not to be an option. Since I do not have a linux based machine, I have tried some other solutions using Grbl first. The best solution that I found was to just post-process the sampled points such that the backlash is accounted for. While this is a bit complicated, it seems to be working out reasonable well so far. I will do some further testing to see if it is an good solution.
I really can't see how it would make sense to tolerate a "floppy" machine, relying on software to correct the slop. Just get the machine right, then you should be good.
