Impossible Bed mesh leveling - Cr10sPro V2

[see3d]

@pitzav

I am having waves in the bed mesh like some people I see here. Its weird but it happens regardless how many points I probe. if I probe 6 in the x axis I will have 3 dips and 3 ridges, If I probe 10 points I will have 5 dips and 5 ridges. So the first point goes “lower” the second higher. The third point lower the forth point higher.
My tests resulted that its not the cr touch -bl touch. Mainly because I did a manual bed mesh with just the nozzle and the pattern was the same.

I have the exact same issue. I am running an MP Delta Pro with magnetic arms. My probe is a Lerdge nozzle probe that measures the pressure between the nozzle tip and the bed. I came to this site to look for bed mesh tools I could use in Klipper to figure it out or at least see if there is a way to improve the bed mesh by doing something like approaching the probe point from 4 directions, taking 4 measurements and averaging the 4 readings to get a much more accurate bed mesh. That would at least cut the errors down at print time by a significant amount. I can not find anything mechanically wrong with the printer. I thought it was something unique to delta printers, but apparently not. As is, the bed mesh calibrate is not giving me anything useful.

For me it is primarily the direction of movement in the X-axis that shows the even/odd ripples in the Y-axis. Interestingly, since I have a delta with 0,0 at the center of the bed, the ripples are gone along the Y-axis at the center. The further from center along the X-axis it goes, the larger the ripple (0.1mm at worst). The even/odd ripples switch places on which is the higher one depending on which side of zero along the X-axis. Grabbing the effector and giving it a shake in all directions does not change the bias. I am beginning to believe one of the 3 motors was commanded to the error position. Still investigating.

[Hertz]

Hello, I have encountered the same issue as you have after doing the Bed_mesh calibration. The first layer that was printed had a broken corner in the lower right, a perfect center, and an abnormally thick corner in the upper left. I was wondering if you have found a solution to this problem.

[ctmal]

So, I’m new to Klipper using an Ender 3 Pro with the 4.2.7 silent board.
I am having the same issue as everyone else posted here so I just wanted to add my experience. I really wanted to use Klipper for the pressure advance features since the Linear Advance in Marlin won’t work with my board.

I ran into the same issue and spent a couple of days trying to get it to work. Generally I use a PEI bed and after running a bed level it was showing that the center of my bed was about .2 lower than the edges. That seemed a little odd to me but ok. Using the first_layer test print from Teaching Tech I was unable to get a good print across the entire board. The front left square always looked good, the back left, horrible(way too high) the center ok, and both right side squares were much too close.
I did do my reading and did set the z offset, made sure the bed mesh was loaded, calibrated the extruder, etc.
Before moving back to marlin, I decided to try my PEI bed again but this time I threw a small piece of paper below the center. After running the level sequence again, it appeared pretty much the same as before. I would have expected the center to be high since I ran through a manual test using a gauge and found the center too close to the extruder. Originally I was thinking that somehow the mesh wasn’t being applied correctly during a print but now I’m thinking that the mesh is wrong.
Anyway, here’s the part that might be helpful if this is in fact an issue. When I went back to Marlin (I have octoprint set up), I ran a bed level. It reported that the bed is higher in the middle except for the front right corner, which is about .15 higher than the center.
I’m now back on Marlin since I can’t get a good first layer on Klipper but I am able to switch back and forth pretty quickly.

Just some extra information in case it is needed, I’m running an OrangePi 3 LTS. I tried a manual install of Klipper on the Debian image and an install of Mainsail OS which uses Armbian. I got the same result on both.

Hope that helps.

[bmurphy1976]

I’ve been watching this thread. I believe I’m running into this issue as well (Ender 3 S1 Pro). I haven’t run the X-Twist Compensation yet (I need time and a feeler gauge) but I did create an install of OctoPi+Stock Marlin to see how that performs and the difference in bed mesh is, well, pretty stark:

Marlin:

Klipper:

I ran a 50x50 mesh because I’m a glutton for punishment but my smaller meshes all have the same problem.

[Sineos]

@bmurphy1976

to see how that performs and the difference in bed mesh is, well, pretty stark:

Unfortunately, these two screenshots cannot be compared. On the Marlin one you have a range from +2 to -2 and the Klipper one is 0.05 to -0.158. That means that the Klipper graph has roughly a 20 times higher resolution than the Marlin graph.

The Min / Max / Var information on the Marlin graph suggests that both pretty much agree.

[Murdock]

Do not look at the shape of the bed as @Sineos said the scales are too different and that of Marlin would tend to give the impression that the bed is flatter but if we zoomed to have the same scale you would have almost the same thing.

On the other hand, looking at the min and max values ​​is interesting.

On klipper we have :

Min -0.158 Max 0.050 therefore a variation of 0.208mm

On Marlin we have :

Min -0.09346 Max 0.064 therefore a variation of 0.15746mm

Assuming that you made sure that the probe points are identical between Marlin and Klipper
(and you absolutely have to), the min values ​​are quite close although 0.0164 already causes a fairly large difference in correction.

On the other hand the max values ​​are very different and assuming that Marlin is right Klipper will strongly overcompensate this side of the bed.

However to be perfectly relevant to analyze you must:

• Make sure that the coordinates of the probe points are reasonably close. (ideally the same)

• Make for example 5 series of measurements on Klipper and do the same on Marlin and make an average, or even determine the median values.

Providing an excel table with the different measurements by probe points, by iteration, and by firmware would I think be the best for the dev teams.
(At least that’s what I would want if I were them)

This information would make it possible to definitively see:

• If there is a problem.

• If the problem comes from the measurement or from the compensation algorithm.

I had started this job but I couldn’t complete my job, leaving me very little time. However, I noticed that by choosing as a reference point a point where the value is almost in the center of the range and by playing on the z-offset I achieved a result that was not perfect but “acceptable”.

Good luck in the pursuit of your tests.

François.

[ctmal]

I can do the research myself but I figure I’ll ask this to save me some time.

I’m looking on how to get the following information both from Klipper and Marlin. Since I am able to swap between the two fairly easily I figure I can try and get some real data.

1. The actual points and values for the probes.
2. If possible, the mesh points. I’m not sure what will be better at this point, all interpreted mesh points or just the mesh values at the probe points. This may just end up being the same as 1.
3. The interpreted/calculated value at each probe point.
4. this would be the most helpful but I’m doubting it’s available. A complete translation of a first layer print job. If possible, the entering value and and resulting value that is processed. Unfortunately I’m guessing this will only be available with changes in logging in the code but hey, if it’s available it will be usefull.

I did read somewhere that you can set up a virtual Klipper printer, if anyone knows whether that’s available in Marlin, maybe that’s a path I can go down too.

Bottom line for me, Klipper isn’t working for me and, being the complete idiot that I am, I’m curious as to why.

[ctmal]

So, I did some reading and apparently Marlin Linear Advance is now supporting my board.
I still wanted to upload some data to try and help out. There are some things I really like about Klipper that would probably make me still change from Marlin if I can get it working.

As some background on how I got this data, I set up Marlin with Octoprint and set up my bed leveling to reflect what I was doing in clipper. From there, I saved a picture of the Octoprint visualizer as well as copied the probed values into a spreadsheet.
From there, I went back to Klipper and tweaked my Auto Bed Level so that it’s now probing the same points as Marlin. I checked it with a caliper(while it was moving so it might not be 100% but its really really close). Then I ran a Home and auto bed level from the LCD. I went into Heightmap and saved the new mesh, then reloaded the mesh and used BED_MESH_OUTPUT PGP=0 to get the probe values.

Here are the pictures of the mesh. Note that the scale for Klipper is -1 to 1 and Octoprint is -2 to 2 so they are not a direct comparison but they are close enough that you can see that the mesh shape is different.

Next, in my spreadsheet I did some comparisons. Before I upload the spreadsheet, let me explain it a bit.
The first column are the values I got from Klipper using 2 probes per point, then the values I got from Marlin with 1 probe per point, then the values from Klipper using 1 probe per point.
For the 2nd column, I figure since I wasn’t sure what the raw data value for 0 exactly was (I’m assuming the z offset), I calculated all probe points compared to the Center Probe Point in the mesh. So, this basically makes the center point 0 and you can see the difference at each probe point.

The 3rd column is a comparison of the Klipper values to the marlin values. For each point in the 2nd column, the Klipper value is subtracted from the Marlin value. I did this comparison because I am able to do all my 1st layer tests successfully in Marlin but not Klipper.

The last column is just a copy of the 3rd column with a color map added to view negative and positive values.

Marlin_Klipper_Comparison.zip (112.7 KB)

The end result appears to me that there is a significant difference in the probed values. I have no idea what would cause this and I don’t know how much of a difference should be acceptable.

I hope this information is useful, if it’s not, just let me know(if it’s useless there’s not point in me spending the time). Also, if there’s any other information that can help, let me know.

As I said before, I have it now that my setup is very easy to swap between Marlin and Klipper so it shouldn’t be a problem.

Edit: Since I’m a new user it won’t let me add the 2 pictures and the spreadsheet in 1 post. I will upload the pictures in separate posts.

Edit #2: Apparently since I’m new here I’m limited to 3 posts, so, I re uploaded the zip file including the pictures. Also, I’m not sure I’ll be able to reply if there are any questions. If someone needs a reply, please let me know how to get around the newbie limitations.

Edit #3: So, I can’t enter more posts but I can edit my current ones. I just took a look more at the data and I found a way to get better pictures in Octoprint. Actually, the numbers do still seem off a bit but the general shape of bed looks very similar when in the correct perspective. I’ll do more research tomorrow.

[Sineos]

Not sure that I’m interpreting your results correctly. General remark:

• With a probe accuracy of 0.005 you have a general error of at least 0.01 in your data
• For Klipper I’d recommend at least 4 probes with a median averaging

[Liatoss]

Well, as many in this discussion, I run into the same problem - almost impossible to do bed mesh leveling. But my case was much simpler and self indicative to find the root of the issue. As I can see here, most of my colleagues tried to do the same, which was completely wrong direction for me.

In my case, I must adjust stepper motors current to illuminate the issue. It is not connected at all with any settings for BLTouch nor bed_mesh in the printer.cfg!

Why I tried to adjust the current: I did upgrade of my printer from stock CR10S Pro with already klipper in it controlled by SonicPad to the CR10S Pro but with Biqu SKR E3 V3.0 motherboard.
In my case, the biggest part of the migration was on electronics part - I made a 30pin connector with soldered wires for 2pins and 3pins JST connectors to get the CR10S Pro standard equipment connected with the Biqu motherboard.
Most of working settings from CR10S Pro stock motherboard were migrated into the the printer.cfg for Biqu motherboard.

As soon as all electronics work properly, I started my tests with printing, calibration etc… and immediately run into the same issue as described here. So in my case the difference was the motherboard and TMC2209 drivers for stepper motors and their parameters in the klipper configuration file.
Biqu provides standard configuration for CR Ender 3, which is smaller and lighter than CR10S Pro, they offer for each stepper x, y and z TMC2209 run_current: 0.580 mA which is too small in case of use of CR10S Pro.

You can check this config file in Marlin and you can see the standard current for those motors is 0.750 mA.
My personal impression, that at bad leveling process, the printer starts loosing steps at least for Z movements and as result the 3D bed mesh surface becomes so choppy. IN Physics measurements, if equipment works well, you cannot expirience such an issue, so, it was obvious for me, the conditions of measurements are different.

So, I start looking for CR10S Pro motors standard current in internet and found this discussion, which gives me the idea how I can tweak motor current to get the system working, hereby are my klipper config related to stepper motors and TMC2209 sections:
[tmc2209 stepper_x]
run_current: 0.800 # 0.580 - default

[tmc2209 stepper_y]
run_current: 0.800 # 0.580 - default

[tmc2209 stepper_z]
run_current: 1.000 # 0.580 - default

So, feel free to give this method a try, hope it can help most of those here who experienced the same problem.

B.r. Vlad.