Auto Bed Leveling is not working correctly

[ghost]

i build a new prusa i2 with a capacitiv sensor for auto bed leveling, the sensing itself works fine. I couldnt test the createt Matrix if its correct, but if i start to print the auto bed leveling works worng, were it should go up it goes down. i think the measurement is correct, but the compensation does not work properly. I'm using Marlin 1.1.0 - RC2 released on 29 September 2015. I hope someone can help me

[Roxy-3D]

Problems reported on RC3 will get more attention.

[handsomedude]

I have the same issue. Worked flawlessly using marlin 1.0.2 but when upgraded to latest rc3 I get the G29 to read the bed surface, but when printing, its like the bed calibration has been flipped.

Left of bed lower than right. When printing, the lower left side compensation happens on the right and vise vera

[KiteLab]

Is you printers coordinate system right handed?

[ghost]

I found the problem, the rods from my x carriage are a little bit twisted, at one site of the bed the probe was bit higher than the other side.

[SeanTasker]

I found that if I issued G29 then attempted a print G28 seemed to be clearing the result of the probe. I modified my slicer start g-code to issue G28 then G29 it worked as expected. I haven't looked at the source code to determine whether or not this is intended behaviour or not. I was using RC3.

[paulusjacobus]

That's exactly the intended result. G28 clears the conversion matrix. G28 and G29 always appear in this sequence never the otherway around.

[hexxter]

i use RC3 and the auto bed leveling doesn't work correct. I measure 3 points left right and in the middle of the front but when i printing it moves in a static way and makes no compensation in Z.

My setting is CoreXY dual extruder.

Have anyone a idea whats going wrong?

[jbrazio]

Could you please paste the output of G29 V4 ? The correct order of commands at the start of a gcode file is:

G28
G29

[Roxy-3D]

Make it interesting: G29 P 5 V4 T

On Sat, Mar 12, 2016 at 1:41 PM, João Brázio notifications@github.com wrote:

Could you please paste the output of G29 V4 ?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2889#issuecomment-195795595 .

[thinkyhead]

@hexxter For additional output to help debug G28 and G29, you can also enable the DEBUG_LEVELING_FEATURE and re-flash the firmware. With this enabled, you can use the M111 S32 command to enable extra output for G28 and G29 V4.

Since you're using 3-point leveling, you can't use the P or T parameters suggested by Roxy. But if you want to try out grid-based leveling, which does use these additional parameters, just enable AUTO_BED_LEVELING_GRID and re-flash the firmware.

[hexxter]

sorry for my late answer.

This is the result from G28 + G29 V4

Bed X: 0.000 Y: 0.000 Z: 30.804 Bed X: 270.000 Y: 0.000 Z: 30.871 Bed X: 135.000 Y: 200.000 Z: 30.692

Bed Level Correction Matrix: +1.000000 +0.000000 +0.000248 +0.000000 +1.000000 -0.000723 -0.000248 +0.000723 +1.000000

[hexxter]

Here with autogrid:

Bed X: 0.000 Y: 0.000 Z: 30.820 Bed X: 135.000 Y: 0.000 Z: 31.016 Bed X: 270.000 Y: 0.000 Z: 30.884 Bed X: 270.000 Y: 100.000 Z: 30.724 Bed X: 135.000 Y: 100.000 Z: 30.972 Bed X: 0.000 Y: 100.000 Z: 30.826 Bed X: 0.000 Y: 200.000 Z: 30.723 Bed X: 135.000 Y: 200.000 Z: 30.711 Bed X: 270.000 Y: 200.000 Z: 30.343 Eqn coefficients: a: -0.00051542 b: -0.00157187 d: 31.00669860 Mean of sampled points: 30.77992820 planeNormal x: 0.000515 y: 0.001572 z: 1.000000

Bed Height Topography: +-----------+ |...Back....| |Left..Right| |...Front...| +-----------+ -0.05680 -0.06930 -0.43680 +0.04570 +0.19257 -0.05555 +0.04007 +0.23632 +0.10382

Corrected Bed Height vs. Bed Topology: +0.24084 +0.29792 +0.00000 +0.18615 +0.40261 +0.22406 +0.02334 +0.28917 +0.22625

Bed Level Correction Matrix: +1.000000 +0.000000 -0.000515 -0.000001 +0.999999 -0.001572 +0.000515 +0.001572 +0.999999

[hexxter]

with autogrid it works...

[jbrazio]

If you do something like this:

G28
G29
G1 Z1
G1 X0 Y0
G1 F1500
G1 X200
G1 Y200 
G1 X0
G1 Y0

You don't see your Z axis slowly moving compensating the plane ? On mine sometimes I have to gently grab my Z rod near the stepper coupler to "feel" it moving.

Try first with 3-point and then with grid-2-point please.

[AnHardt]

@hexxter Your 3-point data is telling a story about a well leveled bed. The corrections would be very small. You grid data tells a story about a convex (warped) bed. The midpoint is, even after correction, about 0.4mm higher than the borders. 3-point testing can not see that. 0.4mm is likely to much to print reliable. Correcting only the slope is likely not enough with this bed. If it does not work for you, try MESH_BED_LEVELING.

[paulusjacobus]

Not sure if I do need to open a new issue or can use this one. Please do let me know and I'll create a new issue.

In the RC3 bug fix release that I am testing, I found that after 1 successful auto leveling and print, the next auto leveling and print seem to increase the gap between the nozzle and the bed (just with 0.1 mm, my offset is just 0.2 mm). My work around is just a quick reset (button switch on Arduino Mega) and start with the next auto leveling/Print.

Both behaviours are on my Prusa Iteration 2 printers (Atmega/Ramps1.4 with fixed promixity sensor hardware). I use CURA as slicer.

[jbrazio]

Are you homing G28 between prints ? G28 should reset the compensation matrix and G29 should set it, nevertheless consecutive G29's shouldn't keep increasing the compensation table.

Can we reproduce the issue only with:

G28
G29
G29
G29

Or de we have to finish a print ?

[jbrazio]

Did you test your z-probe for repeatability ?

[paulusjacobus]

@jbrazio I use the g-start code sequence in CURA for each print like "G28, G29" etc.

' G21 ;metric values ' ' G90 ;absolute positioning ' ' M82 ;set extruder to absolute mode ' ' M107 ;start with the fan off ' 'G28 ;move min endstops ' 'G1 Z15.0 F9000 ;move the platform down 15mm ' 'G92 E0 ;zero the extruded length ' 'G1 F200 E6 ;extrude 6mm of filament ' 'G92 E0 ;zero the extruded length again ' 'G1 F9000 ; Put printing message on LCD screen ' 'M 117 Printing.. '

The g-end code powers down the printer with a M81 command. The Z probe repeat-ability is very good, I recall standard deviation of 0.02 (can do a 'M48' again to report you the actual values).

[Roxy-3D]

In the RC3 bug fix release that I am testing, I found that after 1 successful auto leveling and print, the next auto leveling and print seem to increase the gap between the nozzle and the bed (just with 0.1 mm, my offset is just 0.2 mm)

This exact problem happened once before, maybe 6 months ago...

[paulusjacobus]

@jbrazio

Did you test your z-probe for repeatability ?

Just did the M48 test with result Mean: -0.053477 Standard Deviation: 0.001440

[jbrazio]

My printer gives the following:

Mean: -0.007400
Standard Deviation: 0.004940

I had a look at the code and the compensation matrix is being cleared at G28 and G29 by plan_bed_level_matrix.set_to_identity();.

[paulusjacobus]

@jbrazio I have downloaded the latest RC yesterday and flashed it on one of my printers, so will test it again and see if I can repeat the issue of increasing offset for each subsequent print. BTW the M48 measurement is in mm, isn't it?

[jbrazio]

Please report back your findings. Yes, the unit is mm.

[Roxy-3D]

BTW the M48 measurement is in mm, isn't it?

Note to Self: Don't get sloppy with units. I always lost points on home work because I wouldn't carry the units through the whole calculation.

[thinkyhead]

Always test with the very latest RCBugFix. Sometimes we fix a bug by mistake while fixing something else.

[paulusjacobus]

Ok that's an important point. Since RC4 is out i downloaded that to test it. Will go back to the RCbugfix releases.

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.