Printer Model: Monoprice Delta Pro
MCU / Printerboard: Orange Pi LTS 2 / Lerdge X klippy.log klippy.log (2.3 MB)
Describe your issue:
This post is only for Klipper users with delta printers.
I have a problem with my delta changing Z heights depending on the direction a tower is moving. It shows up in the bed mesh calibrate as a Z shift on every other probed row. It makes the bed plot look like it is rippled. It is worse towards the edges.
I thought it was just my printer, so I spent a week looking for something with some sort of backlash in it. I found nothing.
I mentioned it on another Klipper user site and one user thought my bed was actually rippled (which it is not). I ask him to plot his own bed and it also came out rippled in the same way as mine (he has a completely different printer make). He was totally unaware that he had a problem like mine.
So now I am wondering if this is something that happens to all deltas, or just some deltas. If it only happens to some, then it may be possible to deduce the source of the problem by comparing the different delta printer designs. If it happens to all deltas, then there might be a way to compensate in Klipper for this.
The first order is to see how many deltas are out there and do they have the problem. For me, the problem was real obvious with a 15 x 15 point mesh. Though I was also able to just G1 to a point near the edge of the bed and make an X+1 move, followed by an X-1 move and probe the point. Then X-1, followed by X+1 and probe the point. In my case there could be up to 0.1mm difference probing the same point after arriving from opposite directions. I also wrote a macro that let me probe the bed and I did 4 relative moves and probes at each point. Then I averaged the 4 probes and made a new entry for the mesh. All the ripples on the bed were gone. That is what I am printing with now with better results.
Please reply if you discover that your delta also has this Z offset problem or does not have this problem after testing for it.
Ok I did it. What do you want it for? The printer.cfg is the only thing I can think of that is of any interest, but it discouraged uploading that one. Very confusing. I only want to upload useful information.
I use a pressure sensor temporally mounted on the nozzle. It detects the pressure between the nozzle tip and the bed.
I hear you about under bed sensors. I spent years investigating root causes and redesigning the sensors on the Monoprice Mini Delta. Creating top-of-bed bed sensors made a world of difference in the mesh accuracy.
It does seem very unlikely that the detachable style pressure sensor would give rise to the effect that I see on underbed sensors. Having said that, it is not completely impossible if the pressure that the sensor puts on the bed is more than a few grams of force. Can you put on a link to the type of sensor you use?
I reviewed your linked reports and these problems are not related to each other. The probe itself is not the issue. I have determined that the problem is related to the direction of approach to the probe point, not which point is probed. The probe itself is good.
I can confirm having same issue. After calibration and mesh printer acts like if one ARM is longer - small prints in middle are OK, but if you do ie 250mm circle, on one side is thickness 0.16 and on other 0.22 or similar… After printer restart, same gcode, different side having issue.
I guess problem is related to end switch sensors… I tried to add “Endstop phase - Klipper documentation” into printer.cfg but seems documentation is not up to date and it requesting additional parameters…
For the problem I have, if you reverse the direction of the circle CW vs CCW, the side with the different layer thickness would change, perhaps even a mirror image.
It’s definitely end switch, as I’m able to print full bed prints 1 from 12 with same Gcode and incorrect thickness is changing after each on/off/homing till point initial layer is all just perfect or disaster.
I bet people not complaints about it as majority won’t print full bed prints / till edge and just use middle part 12cm (1/2).
You have a problem with the homing switches repeatability. That is a legitimate problem and deserves to have its own thread.
However, it is a different problem than this thread is about. This thread is about the z height changing based on the direction of travel in a delta machine. That is after homing and no additional homing between measurements.
I actually have the same exact setup as you except I’m using a Raspberry Pi 3B+. I’m still in the process of setting up my config. I was looking through your config and I noticed that the arm length on “stepper A” is vastly different from all of other ones. Could that be a reason for the problem you’re seeing? How did you get that measurement exactly?
Initially, I entered the arm lengths that were measured. However, there is a calibration print object that is an advanced step. I printed out the object (at 1.5x for my printer bed), and then measured all the dimensions and input them into Klipper. Klipper then changes a bunch of mechanical settings to give the best values to compensate for inaccuracies in the overall mechanical system. I think it runs a bunch of simulations to figure it out. It thinks about it for quite a while. The end result is that the printed parts come out much closer to the intended dimensions.
All this worked well. However, it would not have anything to do with the problem I have. The problem I have is some sort of hysteresis from one or more mechanical systems. If it were to be fixed in Klipper, it would have to be on a per arm basis at the inverse kinematics level. I don’t think that is going to happen. I bought a new Core X-Y printer that runs Klipper. It does not have this problem.
