I would like to implement backlash compensation and looking for guidance on where to start.
I have been looking at the Klippy code for moves, but think this would be best in the mcu code. Essentially anytime a direction of a stepper motor is changed, it would first move by the amount of backlash compensation.
Can anyone offer me guidance of where in the code should I start?
Hi. I think the best option is to implement it in chelpers, maybe itersolve.c? Having it inside kinematics code will be even better, but that will require writing the same code for every kinematics. Then have bool[3] variable of current backlash positions, then add/subtract constant defined in printer.cfg. Also there will be an issue with rapid movement, maybe you’ll need to check how pressure advance is implemented.
I hope I helped, and here’s a good manual of klipper’s workflow:
Thank you for the direction. I am going to study this code to get an understanding of it.
I’d really like to help, because I have a delta printer, which, i think, has unfixable backlash, but I don’t know the klipper workflow good enough to be able to change anything in it
I’m in the same position in which I do not know the Klipper software, but I have been studying its architecture to understand how backlash comp can be implemented.
I am very interested in this because I also have a delta printer with backlash like positioning errors. Problem is that in a delta, you can’t just say that there is backlash in the X, Y, or Z Cartesian axis, because if the backlash is in the A, B, or C tower axis it affects all of the Cartesian axis. The compensation would have to be in the delta kinematics code.
However, on my printer I am seeing what appears to be backlash from a move as small as 1mm in X or Y, showing up also as an error in Z position during a bed level probe. You would think that the probe operation which runs all three towers together up and down would clear out any backlash, but not so. So the symptoms would indicate backlash in the towers, but the mechanical operations indicate it is something different. Perhaps the belts are shifting in some weird way but only with differential motion between the towers. That would make it harder to fix in software.
Have you been able to isolate exactly in the mechanics of your delta where the backlash is?
I also couldn’t figure it out. I printed a test cube (should’ve printed triangle) with alternating wall directions to see the backlash, and to my surprise the front facing plane was excellent at the middle, and worse at the sides. I checked toolhead as well as all 3 towers with a dial measure and everything seemed fine. Tested without motor dampeners, retightened belts a few times, greased linear rails… still the same. I think it may be correlated with force, so it’s not a backlash, rather something proportional to speed or force (looking at my results). Here’s the top layer made with my printer (underextruded, but clearly visible backlash):
I said the code can be written outside the kinematics because I think that every kinematics other than “bed slinger” can be estimated as XYZ coordinates backlash. I assume most of people have the same hardware on all delta towers or corexy sides, so as long as they don’t need micrometer precition, it will be fine.
Yes. this is exactly what my bottom layer looks like because every other stripe is running in the opposite direction. I changed to a concentric pattern (giant number of walls), and the problem went away, because every stripe was running in the same direction as the one next to it. For leveling the bed, I make 4 probes, moving the head out and back 1mm in the 4 different directions to average out the “backlash” effect on the Z position. It made a big difference in the first layer. I had to create a custom gcode to “print” to get the data and edited it into a mesh format. Too bad I can not get the built-in bed level to do this automatically with the parameters that are available. I just wish I understood the source of the problem so it could be fixed correctly.
I want this. If you end up doing something, please let me know if you need a tester. I have an Ender 3.
Hi. How’s the implementation going? Did you figure out anything yet?
I haven’t had time to work on this.
Ok. I thought about some workaround - I could create a Python script that is some post processing script for slicers that applies the backlash compensation
I have a Delta printer. Any backlash compensation would have to be applied to each tower individually, which means at the inverse kinematics calculation in Klipper.
Hi. I made some “proof-of-concept-ish” script that applies the backlash to gcode (in form of PrusaSlicer post processing script). It’s by no means perfect, but maybe it can be used to debug what’s going on with these delta printer backlash (I think the cause here may be some acceleration-related inaccuracy, instead of position-related, but I think no one designed XYZ pressure advance yet). Feel free to contribute, comment, discuss, critique etc.
It of course doesn’t work perfectly (the delta printer example - doesn’t keep in mind the kinematics), but in the range of 0.05 - 0.1 mm backlash it may work good enough.
