Impossible Bed mesh leveling - Cr10sPro V2

First of all thank you for taking the time to look into our problem.

I will test this as soon as I have completed the tests you asked.
I was thinking of doing them two days ago but I encountered a small problem at work.
(“spoiler” I start them again a second time to be sure but I noticed something strange)

I really feel this experimental version very well.

Many thanks again !

1 Like

So I redid the 4 tests under the following conditions:

  • Home made machine with misumi extrusion on MGN12 rail on the X and Y axes and 10mm diameter linear
    rail on the Z axis with trapezoid screw at 2mm pitch. SKR E3 mini V2 motherboard.
    (Visually it is an ender5 of which we have changed all the profiles
    and kept only the box for the electronics, the bed and the screen support)
  • Machine enclosed in a box.
  • Each test was preceded by preheating the machine for 2 hours.
  • A cooling time of 4 hours was observed between each test.
  • The test temperature is 90°C
  • CFG :
[bltouch]
stow_on_each_sample: False
probe_with_touch_mode: True
sensor_pin: ^PC14
control_pin: PA1
x_offset: -33
y_offset: -4
samples: 3
sample_retract_dist: 5
speed: 3

[bed_mesh]
speed: 80
horizontal_move_z: 10
mesh_min: 25,25
mesh_max: 210,210
probe_count: 9,9
algorithm: bicubic
bicubic_tension: 0.2

The 4 tests carried out are as follows:

  • Test number 1
Heating ...
...
BED_MESH_CLEAR
G28;
BED_MESH_CALIBRATE
Printing ...
  • Test number 2
Heating ...
...
BED_MESH_CLEAR
G28;
BED_MESH_CALIBRATE
G28;
BED_MESH_PROFILE LOAD=default
Printing ...
  • Test number 3 (to be certain that the loaded mesh does not influence the next origin cycle…)
Heating ...
...
BED_MESH_CLEAR
G28;
BED_MESH_CALIBRATE
BED_MESH_CLEAR (to be certain that the loaded mesh does not influence the next origin cycle...)
G28;
BED_MESH_PROFILE LOAD=default
Printing ...
  • Test number 4
Heating ...
...
BED_MESH_CLEAR
G28;
BED_MESH_CALIBRATE
G28;
Printing ...

Results :
To be brief, none is good.
However, one interesting thing to point out, as soon as you add a G28
after the “BED_MESH_CALIBRATE” (with or without “BED_MESH_CLEAR” and/or “BED_MESH_PROFILE LOAD …”),
you have to increase the Z_OFFSET of the BLTOUCH from 1.98 to 2.08 to achieve identical adhesion and identical crushing.

It may be a misleading track but I find it interesting because it is the thickness of the sheet of paper that we use in the calibration of the bltouch.

The result corresponds in any case to the following “schematic representation” (Sorry for the quality of the diagram, I did this in a hurry).

Overall, this really suggests a drift problem related to temperature, but I find it strange that the fault is always perfectly
identical regardless of the preheating time.
Today I redid 3 tests with 30 minutes of preheating, 2 hours (as in the previous tests) and 4 hours.
When you look at the 3 layers they are 100% identical, it’s impossible to tell the difference… Such a linear drift (although possible) seems quite illogical to me.

Many thanks again for your help !

1 Like

Dear @Arksine,
Sorry to bother you but I have a theory (not super credible but
i have a strange feeling and i need to know…) and to be able to check it I need to know if there is in the firmware a possibility to use a different z_offset in the G28 than in the mesh_bed_calibrate ?
(I searched but couldn’t find it.)
Again sorry to bother you.

No, not generally. The only exception is if the relative_reference_index is configured. This is used on printers like the Voron 2 which home Z to an endstop, it allows the user to offset the mesh so Z adjustment is 0 at the position on the bed where the endstop was calibrated against.

In the general case, bed_mesh passes off the probing procedure to probe.py. When its complete it executes the finalize callback, passing the probed values and probe’s offsets. Bed Mesh uses the z offset to correct the probed values.

Hi I have an ender 3 s1 pro and 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 checked for flat spots, and changed wheels although seeing the pattern increase or decrease if probe more or less I don’t think its the wheels. It has something to do with the z axis, z mottors I think. Its like the head in the first point is correct and in the second is wrong. Maybe it thinks that the print head went higher but actually it went lower so the probe in the next point would result in a ridge.

Randomly the same can happen to Y axis and sometimes in both axis but the number of ridges and dips always follow the number of probe points.
I am only 3 months to 3d printing so excuse any confusing part. :slight_smile: I also had a very warped Y carriage plate and bed and I am waiting for the replacements from Creality if that makes any sense to my issue.

Hi !

Well, different printer (Anycubic i3 Mega-S, 2018 model), same story for me, using an original BLTouch v3.1 (as virtual z-endstop too) and magnetic PEI sheet.
I ruled out every possible mechanical issue, and even made my machine be checked by an engineer friend. From a mechanical point of view, no issue. So, changing my X axis to linear rails or using a different X carriage wouldn’t change anything.
The only thing I didn’t try is moving to an inductive sensor, yet I doubt that would help since my current BLT has a standard deviation of around 0.002mm.

Even with experimental branches, nothing changes. Whatever the bed mesh is, no correction seems to be applied. When something is being printed, it’s always too close on left side, too far on right side, spot-on on center, a hair too close everywhere else.

Exactly the same here.

Neptune 3 Pro - not a BLT, but the exact same issue.

it’s always too close on left side, too far on right side, spot-on on center, a hair too close everywhere else.

Even that is exactly the same.

Something is wrong.

It took my way too long to find my bed problem(s)…but here is the short summary:

My problem was, that the gantry wasn’t perfectly straight. So the angle between the Z-axis and Y-axis (bed) was slightly different on the two z-axis. That caused some torsion on the x-axis.
This torsion will change the offset between probe an nozzle along x-movements.
Depending on the torsion, your bed/offset will be good around the spot where you measured it, but will be way off left and right (along x) of that - in opposite directions.

I tried to fix it, but ended up with a very nice and simple solution:

  • I removed the BL touch
  • I leveled the bed as good as possible by the screws
  • I did a manual mesh: just doing many “paper-tests” to generate the mesh.

For fines meshes, this will be quite some work, but it is immune to almost all static errors on your printer! Did that 2 times in the last 6 months.

After changing the nozzle, just andjust the z-offset and store it, as it will keep your mesh.

To check my result, I printed a 5x5 pattern with single layer squares and measured the thickness with a caliper. with that, you could adjust the probed mesh by tuning the values in your printer.cfg

In fact, that would be a great feature for klipper: having a second “correction-mesh” for the position-dependent nozzle-probe offset. Like doing a 3x3 offset calibration mesh adjust the location bias.

I also ended up by disabling mesh bed and Do manual screw leveling. Perfect 1st layer over the whole bed

1 Like

I ended finding what caused the bed mesh issues on my printer.
As suggested by a comment on YT, I tried to have the probe collinear with the nozzle on the X axis. So I re-resigned my BLT mount for that purpose (offsets are now X=36, Y=0 instead of X=24, Y=-32.5).
I was a bit sceptical, yet it turned out really great. There are two spots where it’s a hair too far (where it was too close before), yet it could be fixed using faulty regions.

At least in my case, it seems the issue was caused by some “twisting” of the motion system over the X axis.
That’s something to checkout, making the probe collinear with the nozzle on X may be the fix in that case.

Chiming in here to say that my Sovol SV06 (Prusa MK3 clone) exhibits this same issue - a twisted x-axis and a probe with a fairly large y-offset seems to be the culprit, in both Klipper and the stock Marlin firmware.

I loaded a custom Marlin 2.1 firmware that has X-Twist correction built in, and while the results weren’t perfect, they were much better than the original Marlin FW without X-Twist, or with Klipper.

I’m going to put Klipper back on later today and try to remount the probe with a closer-to-zero Y offset, and/or just do a manual bed mesh. I expect I’ll have much better first layer results with either approach.

If I can be of any assistance in testing anything please let me know.

Same issue as many others here. 0.2mm variance, mesh is applied during printing, yet one side of the Ender 3 bed is a lot more squished than the other. Paper test and/or bed_screw_tilt are fine.

Hey all, created an account to share a custom klipper module I implemented over the last few days.
Like @whoiswes, I have a Sovol SV06. I was pulling my hair out trying to figure out why my mesh was not correcting for the actual print properly, with the left side being constantly squished than the right.

After some testing, I’ve identified that z-twist is the likely issue. This can be quickly tested using the Probe Location Bias test detailed in the Klipper docs.

The module I’ve implemented allows the user to perform a few manual measurements along the X axis, then create a compensation profile that corrects the Z height whenever the probe is used (such as in a bed_mesh). It has worked very well for me, and I am looking for more people to test it out while I clean up my changes for a PR.

Installation instructions

# change directory to your klipper install folder on your RPI/other klipper host
cd klipper

# add my klipper fork as a remote, and fetch it
git remote add koonweee https://github.com/koonweee/klipper.git
git fetch koonweee

# checkout the new "x_twist_compensation" module and the modified "probe" module
git checkout remotes/koonweee/jt/x-twist-compensation-simple klippy/extras/x_twist_compensation.py klippy/extras/probe.py

Symptoms of this problem/configuration/usage instructions can be found in this document here.

Feel free to reach me at koonweee#0923 on the klipper discord as I may not check back here often.

My pr for the module is available here now, please leave feedback there if you use it :slight_smile:

Hello Jeremy,
First of all thank you for your investment in solving this problem.
Also please excuse me for my bad English, but it is not my native language.

I would just like a precision for the use.

I have a voron 2.4.
The home of the Z axis is done by pressing the nozzle on an endstop outside
the bed and the mesh is made by an inductive sensor with relative_reference_index activated.

I did my calibration and I want to launch a print. In my macro
start_print I have a whole bunch of preliminary operations.

  • Homing (Who does not use the probe but an endstop)
  • QUAD_GANTRY_LEVEL (Who use the probe)
  • Homing (Who does not use the probe but an endstop)
  • BED_MESH_CALIBRATE

Where would you place the statement X_TWIST_PROFILE_LOAD NAME=<profile_name>?

In addition, two underlying questions:

  • Is the compensation always active after a G28?

  • Does the compensation only apply if a mesh is loaded or does it apply to all movements?

Thank you very much in advance for your help !

I sent this response in Discord, but putting it on here too for others to reference

hey thanks for testing it out!

I suggest using X_TWIST_PROFILE_LOAD NAME=<profile_name> before all of the start_print steps. eg:

X_TWIST_PROFILE_LOAD NAME=<profile_name>
- Homing (Who does not use the probe but an endstop)
- QUAD_GANTRY_LEVEL (Who use the probe)
- Homing (Who does not use the probe but an endstop)
- BED_MESH_CALIBRATE

For the other two questions:

  1. The compensation is active as long as there is a profile loaded (using X_TWIST_PROFILE_LOAD NAME=)
  2. The compensation does not affect movements. Instead, it corrects the measurements taken by the probe.

it’s a little confusing to understand, so please let me know if you have more questions

Hello, OMG809

I have a 300 by 300 printing plate, and it is working perfectly fine. Granted, you have a Creality board, and I do not, but that shouldn’t really be an issue. If you would like here are my bltouch settings, and I get fine results with them. I have a CR-10 V2, so very similar to your printer as well.

WARNING: Please do not just try to enter my settings, you will need to change the values that I have commented saying to do so. I just would really hate for you to input them without changing them to your specific values first, as this could lead to smoked boards/bltouch’s, etcetera.

Here are my settings in printer.cfg:
########################################

BLTouch configuration

########################################

[bltouch]
sensor_pin: ^PB2 # this is unique to your mainboard AND YOU WILL NEED TO CHANGE
control_pin: PB1 #this is unique to your mainboard AND YOU WILL NEED TO CHANGE
x_offset: -55 #THIS NEEDS TO BE CALIBRATED FOR YOUR PRINTER
y_offset: -14 #THIS NEEDS TO BE CALIBRATED FOR YOUR PRINTER
samples: 2
speed: 2
z_offset: 4.021 #THIS NEEDS TO BE CALIBRATED FOR YOUR PRINTER
stow_on_each_sample: true
probe_with_touch_mode: false

[safe_z_home]
home_xy_position: 150,150 #this should be the center of your bed
speed: 50
z_hop: 10
z_hop_speed: 5

[bed_mesh]
speed: 80
horizontal_move_z: 8
mesh_min: 10, 10 #!!min and max co-ords are based on the probes location not the nozzle!!
mesh_max: 261, 295 #THIS NEEDS TO BE CALIBRATED FOR YOUR PRINTER
probe_count: 6,6 #this is the number of probing points on X then Y axis
mesh_pps: 2,2
fade_start: 1
fade_end: 10
fade_target: 0

I haven’t tried yet your module, but I have a question before I do.

The tilt of the X carriage relative to the bed is not always linear with X: on a strong gantry like linear rail + 2020 profile or square alu profile you may have constant tilt, if no torsion is present, or a linear one.

I have a corexy with dual rods (one above the other, the printer is a hypercube evolution), which means that even without torsion of the overall gantry, the rods at the middle present more flex (meant as amount of tilting) than at the sides. If there is torsion, again at the middle there is still more tilting than it would be expected taking the average of the sides.

Does your algorithm approximate the manual corrections with a straight line or with a parabola? (Which is not correct but it’s already much better than linear).

I can tell my experience: when I had the bltouch at the same Y as the nozzle, the correction was in general good, even if at the sides less so.
Now that I have also a Y offset, the mesh is unusable. I had to manually add (via postprocessing in Excel!) a linear correction from one side to the other (so I guess that my gantry is twisted).

Your module is therefore useful to me, but it would be even more if the correction were parabolic.

Hey! Thanks for the interest in the module.

You’re correct in stating that the tilt of the X carriage is not always linear, and that a parabolic correction would be the most accurate in compensating for it. However, it would be impossible to model a parabolic correction properly as we cannot directly measure the tilt at all points on the x-axis.

The module instead uses linear interpolation between points that have already been measured.
eg. for X = 20, the module looks up the closest measured points before and after X = 20, and linearly interpolates a correction value for X = 20.

You can change the number of points to measure with this module by using X_TWIST_CALIBRATE N_POINTS=<number of points>. With more points measured, the compensation generated should be a very close approximation of the parabolic correction.

Hello,
after another test with my other voron 2.4, i can say that it is better with this function.
However, this is not yet perfect.
However I used the default config and 3 points for a 350mm bed is not much.
I will therefore redo a test with at least 5 points.

That looks promising !

Thank you for your work !