Ok, here are 3 bed meshes. The first one is turned normally, the second one is turned 90 degrees and the last one is a cheap PEI.
The results are pretty similar. Except the cheap one has a little bulge. It’s not something I can see or feel.
Yes, you have something different, my solution using axis_twist will not help
Although… any >>> repeatable and stable <<< sensors errors can be corrected by axis_twist_compensation (no matter what the nature of the error is). You can still try to make compensation along the problematic axis, with a small number of points, calibration and everything will work normally, (but if the defects are local, for example, in the 20-30mm area install the fix that I dropped above)
Just do manual calibration, for example like this: AXIS_TWIST_COMPENSATION_CALIBRATE AXIS=Y SAMPLE_COUNT=7
(Also in the process, by the numbers you will see whether there really is a problem with the cartographer readings)
I also reread the whole story of your suffering, the first thing to start with for diagnostics is installing a mechanical level sensor (BLTouch, Microprobe etc). I have been researching different level sensors for a long time, and solving various problems with the first layer, and yes - it has never been a problem with the klipper code (except for the above-mentioned case with a bug in axis twist, but this is not the reason, this bug simply does not allow using it to fix the cartographer problem)
I have a Clicky Probe, I just need to print some parts for it. I can try it and see what happens.
I’ll take a look at my homing.cfg and my endstops. The probing behavior seems a bit off—npr I make ztilt ajust so on the right side, it moves slightly over the edge, which suggests it might not be homing in the center of the bed.
But I also experienced something strange for the first time today—my left X joint hit my left front idler. This suggests that something has altered the stepper motor steps.
I need to take a closer look at it. So far, I haven’t done manual axis twist compensation, only automatic compensation. However, the klipper crashes in the middle of the process, but usually on the second attempt, it completes the calibration.
What you’re experiencing reminds me a bit of what happens when Cartographer Survey isn’t being used.
Automatic calibration may not work if you have a problem with the cartographer readings.
Also keep in mind that if you do a calibration (it doesn’t matter whether it’s manual or automatic) axis twist, given that there is already a section with the results of the previous calibration in the “basement” of the config, the new calibration will occur on top of the old one, which will naturally only worsen the problem. That is, before calibration, you need to delete the section in the “basement”.
By the way, your whole problem may be due to calibration “layered” on the previous calibration.
I’m not entirely sure I understand where you’re going with this, but I knew that sooner or later, someone would bring up something like what you mentioned.
So, because it’s open-source and no one owns it, I can’t express my frustration? Am I just supposed to accept that I’ve spent two months and a lot of money without being allowed to talk about it? I’m mentioning it because I hope someone will offer help—not like all the other times where I’ve asked and been ignored.
My frustration comes from the fact that I see many others experiencing the same problem, yet it’s either blamed on user error or the probe they’re using. The possibility that Klipper itself might have a bug is never considered.
This time, however, environmental factors were mentioned, which is at least an acceptable explanation.
If I don’t bring this up, how is the software supposed to improve? Klipper also has other bugs that remain unfixed because people like you show up and say, “You can just stop using it,” or because it is free and open-source—live with it.
I’m using an official version of Klipper—what makes you think otherwise?
As for my probe, I wasn’t aware that it needed to be flashed with Klipper firmware. The documentation is as long and complicated as the Old Testament—how am I supposed to figure out that Klipper requires a different firmware for Cartographer probe and that these two probes aren’t officially supported?
There are thousands of people using these probes without flashing them with Klipper firmware. So, the problem likely isn’t in the firmware. And so far, no one has even suggested that it is.
I’m glad you’re happy with your old-school probe, but the rest of us are using newer ones. In my case, my printer came with Cartographer pre-installed.
And what exactly are you trying to say? That I can’t buy titanium screws for my X-beam because Klipper doesn’t officially support it? That I should throw away 90% of my printer just because Klipper doesn’t support something I didn’t even know about?
And on top of that, am I supposed to sit here and study how the Klipper license works, then learn how a slicer license works, and so on?
Some of us intend not to be experts or spend all our time in one place—we just want to 3D print and seek help where it makes sense.
In this case, the issue was that Klipper is overcompensating for the bed mesh. There might be a solution, but it doesn’t look like one exists.
And from the answers I’m getting, it doesn’t seem like flashing my probe with Klipper firmware would solve anything either.
And sorry, but—are you an expert on Eddy Current probes? Have you ever taken one apart and debugged it? You mention that they’ll “suffer” from magnets and metal—did you test this yourself, or is this just something you read somewhere? Maybe a rant from someone who doesn’t like new technology?
They don’t work with embedded magnets, that’s true. But they work perfectly fine with a glued magnet mat and perfectly fine with metal. In fact, metal is what makes them work.
My intention has never been to demand anything from anyone. But I do believe that it should be possible to point out that the software might have a bug, and I also believe that people should be open to questioning the first and most convenient explanation. These discussions can contribute to improving the software.
However, I’ve realized that there isn’t much help to be found on the Klipper forum, so I will look elsewhere. This entire discussion isn’t helping the actual issue—it’s completely irrelevant to the functionality of the probe and Klipper.
Do I just delete the files, or do I delete Klipper and reinstall it? I have experienced strange bed mesh right after axes twist compensation.
I’m using an official version of Klipper —what makes you think otherwise?
Well, your log.
Git version: 'v0.12.0-438-gbf5c4daf8-dirty'
Untracked files: klippy/extras/gcode_shell_command.py, klippy/extras/cartographer.py, klippy/extras/idm.py, klippy/extras/scanner.py
....
Loaded MCU 'scanner' 71 commands (CARTOGRAPHER 5.0.0 / )
MCU 'scanner' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_spi1=PA6,PA7,PA5 CARTOGRAPHER_ADC_SMOOTH_COUNT=16 CLOCK_FREQ=48000000 MCU=stm32f042x6 PWM_MAX=2 RESERVE_PINS_USB=PA11,PA12 RESERVE_PINS_crystal=PF0,PF1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
It should not be dirty, I should be able to trace a commit on GitHub, and there should be no “extra” stuff.
Otherwise, it is a modification, in that case in the code that is responsible for probing and meshing.
And from the answers I’m getting, it doesn’t seem like flashing my probe with Klipper firmware would solve anything either.
Well, it is unsupported, but you know what you are doing.
So, the only way use cartographer hardware with vanilla Klipper to say there is a bug is to flash it and make it work.
There are thousands of people using these probes without flashing them with Klipper firmware. So, the problem likely isn’t in the firmware. And so far, no one has even suggested that it is.
Well, if that is so and there is a bug, then they all have a special not-buggy klipper.
That I can’t buy titanium screws for my X-beam because Klipper doesn’t officially support it?
Well, you can, but it is a little strange to hear after “I’ve spent two months and a lot of money”.
Make up your mind.
That I should throw away 90% of my printer just because Klipper doesn’t support something I didn’t even know about?
Nope, it means that if you have a problem with your modifications, you are responsible for them.
And sorry, but—are you an expert on Eddy Current probes? Have you ever taken one apart and debugged it? You mention that they’ll “suffer” from magnets and metal —did you test this yourself , or is this just something you read somewhere? Maybe a rant from someone who doesn’t like new technology?
I’ve seen your bed mesh and I bet your bed physically does not have waves.
So, it is one of the effects of the eddy current probe, or all of your beds came from the same metal sheet and bend in the same way. You can choice what you like more.
FWIW, if you have such a flat bed with less than 0.1 mm deviation as reported above, you don’t need a bed mesh, even with a 0.2mm layer, you will have ±25% error on the first layer, which is pretty acceptable.
With your attempt to print with 0.35, you will have around a 14% error.
1 Like
You are completely incomprehensible.
You suggest that I flash my probe with Klipper and use it as an LDC1612 sensor. This has not been tested, and the developer warns about possible nozzle crashes.
It makes no sense to suggest something that is neither beta-tested nor stable and could result in nozzle crashes. On top of that, the developer explicitly states that it currently does not work with slow Z probing, meaning nozzle crashes at high speeds.
I am not interested in replacing one problem with another.
You seem to be a die-hard Klipper fan, obsessed with keeping everything “clean.” It’s fine if, in your world, having a few extra Python files makes something “dirty.” But adding extra Python files does not mean Klipper is modified.
If you don’t understand how this probe works, then don’t comment.
Furthermore, Klipper flags almost everything as “dirty.” For example, ShakeTune—a far superior tool. And unlike Klipper, ShakeTune has an active community where people help analyze the graphs. Naturally, people will choose a tool where real help is available.
When users come to a forum and are either ignored or given dismissive responses, it’s no surprise that they turn to alternatives like ShakeTune.
And what exactly do you want? You are clearly not here to offer a solution to the problem. If you are just looking to point fingers, then find another place—there are plenty of places on the internet where you can find people to argue with.
This is completely absurd.
So, to summarize. You come here, alleging that:
- Klipper has bugs.
- Nobody cares about these bugs.
- The Klipper project has a demeanor of being unimpeachable and above any suspicion.
- The supporters here and on discourse are effectively jerks who do not know what they are doing and only foster this above demeanor.
- Modifications to the Klipper code virtually have no impact.
All of the above without giving any kind of justification, proof, or analysis, except your frustrated language.
To quickly address the five points above, without going into much detail, because the proof can easily be collected here, on discourse, or on GitHub:
- Yes, maybe there are bugs, as in every other software product.
- All such reports are carefully triaged and usually found to be rooted locally and not systemically inherent to Klipper. If there is a doubt, considerable effort is spent by the developers here to analyze it. If a bug or regression could be identified, it is typically closed quickly.
- This might be a matter of personal perception. I don’t think so.
- This might be a matter of personal perception. I don’t think so.
- As with any other software, a single line of wrong or misplaced code can bring down the entire system. Klipper, due to its unique features, is very sensitive in many areas and requires in-depth knowledge and due diligence when modifying it. This is also the reason for marking modified installations “dirty” (the wording could be discussed).
With each and every post, you made some points very apparent:
- You lack knowledge about Klipper and just assume a lot of things.
- You turn down any advice from highly skilled and experienced Klipper developers.
- Your printer and whole setup is not even able to execute the most basic functionalities in a stable manner.
I consider your behavior disruptive, uncooperative, and even brazen. Being very well aware that this now entrenches your preconceived and hardened opinions, I’ll close this thread now.
You are very welcome to post in an upbeat tone, be cordial, and give the benefit of the doubt that all collaborators are trying their best to improve the software.
Please be warned that I will not tolerate any such dramaturgy as above in any potential new thread.
4 Likes