Inconsistent layer height

General Discussion
1

Basic Information:

Trident 300
Octopuss V1
Respberry Pi 4
klippy.log

issue:

I don’t know if this is the right place to ask. But I get inconsistent layer heights.
On an area of ​​140mm there my nozzle may be too close to my print bed and on the other end so far that there is no bed addition.

I use Cartographer probe, and have just ordered a beacon to see if it is better. But I fear that the problem will also be the same with beacon.
What I have done to solve the problem is to take my entire gantry apart, and reassemble it, and make sure everything is straight and tight. I have adjusted my probe and made sure it is straight and has the correct offset. I have got a new Xbeam, and Alu xy joints.

But my bed mesh is exactly the same as before. Any ideas on what I can do from here?
…
klippy.log (123.9 KB)

bed2
bed21827×757 156 KB

20250225_145154
20250225_1451541920×2560 415 KB

20250225_164341
20250225_1643411920×2560 482 KB

20250225_164407
20250225_1644071920×2560 659 KB

20250225_164412
20250225_1644121920×2560 600 KB

2

You don’t have a bed with embedded magnets do you ? If so that type of bed scanner won’t work. I only ask because the height variations seem to be in a pattern across the bed. They are also sensitive to where they are installed in relation to hot end. I considered trying one but decided against it since I my bed really don’t need meshed often plus I switch between glass and flex plates frequently.

3

There are no embedded magnets in it. There is a magnet mat glued on which works with these mats.
It is instilled in the correct position. But I have seen that some people choose to give it a negative Y offset in relation to the nozzle. So I can try that and see if it works then.

4

ok, I haven’t solved the problem. But according to the internet it’s a Klipper bug. It’s been around for more than 2 years now. I’m still looking for a solution for it.
It’s crazy that there are so many people frustrated with this, without a solution.

5

No bug is currently known and some issue that could affect this under certain conditions have already been fixed a while ago. See homing: Log a warning if probe alters stepper kinematic positions · Klipper3d/klipper@31fe50f · GitHub. Your log does not indicate this issue.

I’m also not sure what your problem exactly is:

  • Your first layer seems OK
  • No bed is fully even and yours seem to be quite good according to the screenshot
  • If anything it seems over-extruded
  • All probes with an offset in X and / or Y could suffer from location bias.
6

In the picture, it’s the petg that’s forgiving. But the problem is that Klipper overcompensates for the bed mesh. At the low end of my bed mesh, the nozzle comes very close to the bed, and at the high end, the filament has almost no contact with my bed. Precisely like this video
I have a 300x300mm bed, and I can at best use 20 percent of it with ABS.
If you look at the pictures, on the same object that is 140mm long, the nozzle is way too close to the bed, and the other end, you can only see the bed through the filament.

I’ve tried changing the bicubic from 0.2 all the way down to 0.001 and I see no difference at all. none at all.

I can take my gantry apart again, and try with another xbeam. But I’m not sure if it will work. I get the same result with my new xbeam as I did with the old one.

Here is my probe accuracy test for the area in the image, which shows that they are very close to each other.

probe accuracy results: maximum 1.748038, minimum 1.745932, range 0.002106, average 1.747197, median 1.747217, standard deviation 0.000575

probe accuracy results: maximum 1.794349, minimum 1.792773, range 0.001576, average 1.793534, median 1.793599, standard deviation 0.000544

7

I have spent almost 2 months trying to solve this problem, without any kind of result. I have printed new parts for my Z axes, got cnc parts for my gantry. It seems like it is a never-ending screw.
Since there is no documentation and no one knows how to solve this problem, I have to take my gantry apart again as a last resort to check if everything is ok even though I have done it once.
It is incredible whether it is on discord or forum, as long as it is easy solutions to insignificant things, there are many who know how to solve things. But when it is a problem that is persistence, no one knows what the problem is.
I have a 300x300 printer, it is almost useless. I have to look at the bed mesh every time and place my objects according to it to be able to print simple things.

8

Please be more specific about what you are implying here:

  • What kind of documentation is missing?
  • What sort of analysis is missing, in your view?
  • What kind of figures or statistics do you have that indicate a relevant portion of Klipper installations are affected by such an issue?
  • What analytic steps have you taken to validate that it is not a local problem on your end but a systematic issue?
  • What kind of remote problem-solving capabilities are you suggesting to improve this apparently missing capability for the Discourse or Discord supporters?
1 Like
9

I don’t know how much more specific I should be. I’m looking for documentation on what to do when Klipper overcompensates for the bed mesh. It compensates way too much—in the blue area, the nozzle gets far too close to the bed, while in the red area, it moves too far away, to the point where there’s no bed adhesion.

If you zoom in on the pictures, you’ll see it more clearly. For PETG, I use a large extrusion on my first layer—but I kind of have to in order to mask the mistakes that are there. I use a first layer height of 0.35mm.

If documentation on this issue isn’t missing entirely, it’s certainly difficult to find.

I’ve already described what I’ve done—check my previous post. I’ve installed new parts for my gantry and Z-axis and used two tools thise https://www.printables.com/model/1060868-cartographer-probe-nozzle-offset-tool and thise https://www.printables.com/model/1103427-cartographer-3d-beacon-3d-simple-manual-offset-hel to locate the X and Y position of the probe relative to the nozzle. I’ve also modified my print start macro by adding an extra home before Z_TILT_ADJUST and another after bed mesh calibration.

I recently disassembled my gantry again to ensure nothing is twisted. I’ve adjusted bicubic_tension from 0.001 up to 0.4, and after that, I tested mesh_pps from 2,2 up to 3,3.

I wiped everything from my Raspberry Pi, reinstalled Klipper on a new SD card, flashed my MCU, and reflashed my Cartographer probe.

Yet, the issues persist. Things worked fine for the first two days, then all the bugs came back:

  • Virtual SD card errors
  • Moonraker constantly disconnecting from Mainsail
  • Klipper3D crashing in the middle of axis twist compensation
  • Klipper3D still overcompensating for the bed mesh (the biggest problem)

At this point, I struggle to see how this could be user error, considering everything has been reinstalled and reflashed from scratch.

What I’m looking for is at least a hint about what could be causing this. Ideally, solutions should be clearly documented in Klipper’s official documentation.

Maybe the solutions are there, but the documentation is as long and complicated as the Old Testament. After spending two weeks trying to understand and implement it, it still doesn’t work because I was looking in the wrong place.

Now I’ve disassembled my gantry again, and when I put it back together, I’ll try the probe location bias test—although I have no idea how it will help. If it turns out to be a probe location bias, then what? There’s no solution for that.

Right now, after two months of troubleshooting, spending a lot of time and money on this project, it’s not fun anymore—not fun at all. It’s frustrating to deal with a dead Klipper forum where no help is available, and the same can be said about Discord.

I’ve asked for help multiple times and received no answers at all. The best response you get is that “Klipper has no bugs; it’s always user error.”

Maybe it is a user error, maybe not. But when there’s no solution, how are you supposed to know? And I don’t see how it can be a user error when you’re following an installation guide step by step.

At this point, I’m just going to keep trying to solve this and hope that, like the guy in that video, I won’t have to sell my printer.

10

It doesn’t look like your probe is sampling accurately. Its very unlikely that your bed has “waves” in it along the Y axis. Even adjacent samples along the X axis don’t appear consistent. Bed mesh is only as good as its input, it will appear as if its under/overcompensating if the probe does not provide an accurate reading.

In addition, probes like the cartographer introduce their own code modifications to bed_mesh. If there is a bug in the software it is likely something they will need to correct.

1 Like
11

Those “waves” could possibly be caused by my rails. I cleaned them thoroughly, and they felt smooth, but there could still be an issue with them.

There might also be something wrong with my probe.
I ordered a Beacon probe last week and hope that solves the problem.

When I run Z_TILT_ADJUST twice in a row, it adjusts the Z tilt both times—the second adjustment is smaller than the first. So yes, maybe something is wrong with my probe.
We’ll see when the new probe arrives.

However, that still doesn’t explain the overcompensation.
Based on the first layer tests I’ve done, a good enough bed mesh is generated. If Klipper compensates more in the blue areas and less in the red ones, then the bed mesh should be accurate.

But it overcompensates, and adjusting bicubic_tension does nothing, which suggests something is wrong.

I’m trying to get help on the Cartographer Discord to see if they can help with the bed mesh, since they modified the code.

I’m also experimenting with homing, probing speed, and current.

One thing I don’t understand:
A search shows that many people have the same issue, whether they use Beacon, Cartographer, or BLTouch.
Does that mean they all implemented the same bug in their modifications of the software?

12

The bicubic_tension setting isn’t going to have any impact, it simply alters the amount of slope used to interpolate points between samples. Given how densely you are sampling the surface there is no value provided by interpolating extra points, interpolated samples will closely approximate linear interpolation regardless of the tension parameter.

If you think that the mesh is accurate then what you describe suggests there is some kind of movement issue on the z-axis, at least in my experience. Binding, lack of torque, backlash, etc. FWIW, I have had first layer issues with a BL Touch on a printer. I swapped it out for an inductive probe which corrected the issue. That said I know others who are running just fine with a BL Touch.

I’m sure you can find dozens of people with first layer issues using an internet search, regardless of the probe, printer, etc. What you aren’t seeing are the thousands of people running Klipper and bed_mesh without issue. If bed_mesh is producing invalid adjustment calculations it should be unusable across all printers.

It doesn’t rule out that there is some kind of issue impacting a subset of printers with a very specific configuration, but its unlikely. I have spent countless hours chasing down this ghost. In my testing I cannot get bed_mesh to produce adjustments that aren’t what is expected. If I receive data and logs showing that bed_mesh is miscalculating adjustment that its something I will certainly look into.

To be clear, I’m not saying this is “user error”, instead I believe there are environmental factors at play, and these factors can be extremely difficult to chase down. 3D printers are complex machines with a large variety of hardware, software, and electronics that must operate with sub-mm precision.

1 Like
13

You can try the solution I described here (edit your axis_twist_compensation.py and do manual calibration by 30 points, maybe even automatic will work with this fix).
I described it a month ago, but it was ignored…

Also more details:

The problem is that with the current axis_twist_compensation.py code, the calibration points from the section

[axis_twist_compensation]
#*# z_compensations
y_compensations

are shifted by 2, i.e. they are not applied to the coordinates that were measured during calibration.

The problem is in the uneven magnetic properties of the PEI plates (I have the same problem on 3 of the 4 plates - areas (bands) where the cartographer gives incorrect readings. Although axis_twist_compensation is not designed to correct this defect, its operating principle allows it to be compensated.

axis_twist_compensation.zip (4.1 KB)

1 Like
14

Hey thanks. I’ll take a closer look. I’ll have to adjust things one last time so I’m sure I don’t have anything twisted.

But Carto survay doesn’t care how strong a magnetic field your bed has. It measures in a different way, so if you have a bed that has different magnetic pulls in different places, it wouldn’t matter to the measurement. That means it measures more precisely now with survay.

1 Like
15

I’m not saying that Klipper doesn’t work well or that it doesn’t work for thousands of people. My point is that it does work for thousands of people—I’m just among the hundreds for whom it doesn’t. And our problem is ignored.

There is also research on this: when thousands of people report something working, the minority with issues tend to stay quiet to fit in.

I don’t have a unique or complex configuration—I’ve kept everything as standard as possible. If you need logs, I have them. And when I receive my Beacon probe, I can also send you my Cartographer probe.

It makes more sense when you say that environmental factors could play a role. Because at this point, it no longer makes sense to blame user error or specific probes like Cartographer, Beacon, or BLTouch. These probes simply add a few extra Python files with additional code to make them work.

Beacon took the idea from BDscanner and made it closed-source, while Cartographer took the idea from Beacon and made it open-source. This means the source code is available, and you can see exactly what it does.

But regardless, it doesn’t seem like my issue will be solved here. This feels more like a defense of how “flawless” Klipper is rather than a real attempt to identify possible bugs.

Klipper does have bugs, but people hesitate to say it out loud because they’ll be drowned out by the hundreds of users with old bedslingers that don’t require much to run well.

I’ll check Murdo’s threads to see if I can find anything helpful. Otherwise, I’ll have to search extensively online. I won’t be buying any new probes until I see clear evidence that these advanced solutions work properly with Klipper. I can only hope that the Beacon probe I ordered—before realizing the extent of the problem—works when I receive it.

I hope there are no hard feelings, and that going forward, you’ll be more open to the possibility that Klipper may have bugs.

16

A couple more tips to understand whether you have the same problem as me or not.

  1. Turn the plate 90 degrees, if the problematic stripes on the mesh surface along with it - that’s it.

  2. If possible, take the mesh with a mechanical touch without heating and compare with what the beacon/cartographer mesh, without this you can guess what the problem is.

  3. Don’t be lazy to print a test of the first layer IN THE ENTIRE print area (not a cross or a frame - a solid first layer) to understand whether the defects are really in the form of lines.

17

I have tried and turned my pei plate, and tried 3 different plates. They all give the same bed mesh.

But I just got a new problem. When I do a ztilt ajust, my left xbeam joint bumps into my idler.

I have measured with a ruler and it looks like there is the same amount of distance between my xbeam and left idler and right idler.

It only does it after a firmware restart otherwise it doesn’t.

18

I see, it looks like you have a different problem, or the same one but for other reasons.
Can you send screenshots of the mesh of the same PEI sheet rotated by 90 degrees? The differences may not be very large, the general shape of the table will still be captured correctly, but an error of 0.08 mm is already enough for problems with the first layer.

19

Yes, just give me 10 minutes, I need to adjust my front idlers.

In reality, the problem could be that the coil on the probe is broken and doesn’t have the resistance it should have.

20

Well, I hear your frustration.

First of all, this is an open source community, if you spend a little time reading the license, you will realize that nobody owes anything.

  For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software.  For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.

So, if anyone, literally anybody, tries to help you, he does so in their free time and in good will.
No one forced you to spend time or money, get a 3d printer, use Klipper, or buy a <name a thing>.

The second, logs is nice, but they do not provide the full picture, from peeking at cartographer code they do alter BED_MESH and other commands.

    cmd_BED_MESH_CALIBRATE_help = "Perform Mesh Bed Leveling"
    def cmd_BED_MESH_CALIBRATE(self, gcmd):
        method = gcmd.get("METHOD", "cartographer").lower()
        if method == "cartographer":
            self.calibrate(gcmd)
        else:
            self.prev_gcmd(gcmd)

No one knows which one you use.

The third, as implied by the License and also described here:

You have a modified klipper version.
If you wish to file a bug or insist on having one, you need to have a pristine Klipper version.
You may flash the cartographer with klipper, configure it as LDC1612, and then try again.

So, right now, you have an unsupported probe, and you buying another one, which changes nothing from a support perspective.
Unsupported hardware on a modified klipper version.

It is maybe fine, if you have an issue in another place, it can be ignored. But you say you have an issue with the first layer - so with the probing.

Btw, I do not have a bed slinger and do not have first-layer issues with bed mesh.
PEI + old fashion inductive probe
It may not be ideal, but I have no way to make it better, so far, so good.

Fourth, the Eddy Current probe can and will suffer from magnets, metals, internal stresses, metal internal magnetic domains & etc. You may think they do not suffer from it, but they will.
So YMMW.

1 Like