This resembles behaviour I am fighting on my Fysetc Cheetah 1.2 for weeks. I have to attend each print as it starts and compensate actual Z offset on the fly via Tune menu (PITA). That is if I even have a chance.
Anyway, what I in fact am experiencing is that Z offset exponentially increases with every G29 performed.
If I represent median of billinear level grid values of first G29 after reset as "0", then 2nd consequtive G29 incerases Z offset by 0.015mm, 3rd G29 by another 0.03mm, 4th G29 by additional 0.05mm, 5th G59 by yet another 0.065mm, 6th adds another 0.008mm, etc.
In result, sending 7 consequtive G29 commands in a row changes Z axis offset by roughly 0.4mm(!)
Resetting or power cycling mainboard returns grid values back to "0" and rollercoaster ride begins again.
I have this issue on fresh build of bugfix-0.2.X as well as with archived build from early August.
G29 Z axis offset change.txt
.

salacpavel on 3 Oct 2019

@salacpavel
You have the same problem as mine. Check the height of the Z axis after the G29 command.
I changed the starting script and I'm still lucky with the first layer, but this is a crutch.
G28 ;move X/Y/Z to min endstops
G29
G0 X-10 Y6 F5000
G29 ;replay
G0 X-10 Y6 F5000 ;replay
M109 S[extruder0_temperature] ;Extruder (wait)

komandrik on 3 Oct 2019

👍1

I am also observing another weird aspect of ABL billinear feature that I think is somehow related. Unfortunatelly, its very hard to pinpoint or even describe properly. However, what I see, especially with latest builds, is that actuall first layer does not perfectly follow height of printing surface - like the mash is not calculated or rather to say "applied" properly across the entire print area.
As I have mentioned, while I have seen this already with August builds, I have been able to overcome this by squishing the first layer by 0,02 or 0,03 down more. But whenever I switch over to fresh vanilla build to check it out these days, the issue is so significant, that this is not possible anymore, without risk of scratching HB. The 1st layer of 15x7cm print is simply so low on one edge that it curls, while its already lifted off the bed on the other side.
This all is on basically perfectly flat HB (see G29 reports in my last comment) so almost zero mesh compensation should be needed.
I am also getting near perfect 1st layer with manual bed leveling.

salacpavel on 4 Oct 2019

@salacpavel try this starting script:
G28
G29
M500
M420 S0
This script should force the further use of auto-alignment.

komandrik on 4 Oct 2019

I have the same problem and can share some details on it:
I upgraded from RAMPS 1.4+2560 (had marlin from spring of 2017) to SKR 1.3.
ABL_BILINEAR in use as I have 370x280 bed (custom corexy printer with nozzle probe based on Voron 1.4-1.5). Home is in the corner of machine, but safe_homing is defined and G29 probes in the middle of bed.

On Atmega I never had to mess with the probe height offset. It always worked and all prints worked fine and never needed to observe the first layer. I never leveled bed again and as I have 3 screws moving the bed up and down they went out of sync a bit over the years.
This led to bed to being ~3mm uneven (-1.3 on other end and +1.4 on the other on G29, ~0 in middle).

Now the upgrade to SKR and TMC2208/2209 and using mostly the same configuration as on atmega (a lot had changed) the bed leveling is way off. I had to put the probe offset to ~1.45 for prints to work and it was not that reliable. Then I physically leveled the bed as I upgraded the Z axis from M8 to T8 (G29 shows max 0.13 off) and now I had to set the probe offset to its proper value I had in atmega around 0.08.

Clearly some offset from the ABL is not applied or is applied at wrong point (origin in corner and z-home in center).

Neverther on 6 Oct 2019

I have a similar problem. (But this is UBL) Printing perfect all over the bed without UBL.

The problem arises when I've probed the entire bed ...and edited the mesh.... and then do the last calibrating of Z-offset.

When I do this, the whole mesh is changed with numbers that do not fit into the equation with Z offset. I could understand if the numbers was added the Z value, or anything with the Z offset value.... But it dosen't.

I also tried to use "Tune" Z-offset when printing. I decrease the Z value, so the print is perfect. Take this value and store it with M851. Then look at it with G29 L1 T and the mesh is changed.

I'm running Bugfix 2.0.x on SKR 1.3 v. PlatformIO from 6/10-2019
I have also tried this on 2.1.x-dev, same result.
Z Probe offset= -0.53 mm

tvixen on 7 Oct 2019

@txvixen I think it would help anyone reading this if you posted the output of G29 T before and after you have adjusted the Z offset. Also are you sure you are comparing the same mesh? G29 L1 T will be loading a previously saved mesh from eeprom and displaying that, not the current state of the mesh.

gloomyandy on 7 Oct 2019

@tvixen and why again set offset_z after manually calibrating the Bed level? Offset_z needs to be set once, before building the grid and do not change it anymore.

komandrik on 7 Oct 2019

@tvixen and why again set offset_z after manually calibrating the Bed level? Offset_z needs to be set once, before building the grid and do not change it anymore.

Yes, I see your point, problem is that after G29 P1 and P3 you have to edit the mesh manually. As some of the points af wrong. After this save G29 S1 and a test print, the print is not 100% close enough to the bed, so I adjust it by M851 as it prints. Thats why I change Z after calibrating.

But I will post the Output later today.

tvixen on 7 Oct 2019

In order to keep printer working, I have resorted to ABL_LINEAR instead.
Anyway, since I have also noticed there was quite a big change on bedlevel.cpp yesterday, I have decided to give fresh build a try. My first observation is that G29 T now reports very different values and my bed suddenly does not seem to be level anymore. Hopefully these values are correct now.
However, test print did not go well: Z does not remain down now when G29 finishes and it rises back to 5mm height as printhead moves tovards x,y:0,0 and it begins to print mid air.

salacpavel on 7 Oct 2019

Another observation. Whenever I now try to execute G29 second time in a row, it always fails probing the first point as follows:

>>> G28
SENDING:G28
>>> G29 T
SENDING:G29 T
Bed Height Topography:
   +--- BACK --+
   |           |
 L |    (+)    | R
 E |           | I
 F | (-) N (+) | G
 T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
 +0.03389 -0.05611 +0.06639
 -0.10611 -0.00861 -0.10611
 +0.05139 +0.02389 +0.10139
>>> G29 T
SENDING:G29 T
Error:Probing Failed
[ERROR] Error:Probing Failed

Yet with previous build, I could call G29 all over and over, all passing. Now I have to home with G28 every time before i can call G29. Then and only then it passes.
EDIT: Seems like same root cause - an extra 5mm height.

salacpavel on 7 Oct 2019

😕1

Yet with last build, I could call G29 all over and over, all passing. Now I have to home with G28 every time before i can call G29. Then and only then it passes.
EDIT: Seems like same root cause - an extra 5mm height.
I can also confirm that 2.0.x can't use G29 without G28 first.... don't try it.
But 2.1.x-dev working fine in that point.

In Version 2.0.x it's not possible to edit the mesh, as it will stand still on the same XY , just changing the LCD with the correct values.
In Version 2.1.x-dev edit the mesh is working perfect. But M851 seem to be missing the X and Y values(as it had in 2.0.x). So in this version I will not change the Z-axis any more. The Z axis is set to "0" in the firmware, and the mesh values is adjusted to the bed( individually).

I will now do the test print again.

tvixen on 7 Oct 2019

Stated rhis on discord, too. So far no response.

Bilinear is bugged and linear wont move z if bed leveling (m420 s1 or after g29/g28) is active, wont move (neither wth g0/1 or while printing. Tried with latest commits today, same result.

Disabling leveling with m420 s0 and z will move again.

Sry, wrote with mobile :p

reloxx13 on 7 Oct 2019

As promised:
This is with version : 2.1.x-dev
After a G28, G29 p1...and edit the mesh to my needs.

Printer Output Log

SENDING:G29 T
Bed Topography Report:
    (  5,220)                              (220,220)
        0       1       2       3       4       5
 5 | -0.025  -0.265  -0.460  -0.615  -0.730  -0.825
   |
 4 | +0.065  -0.190  -0.385  -0.490  -0.655  -0.710
   |
 3 | +0.100  -0.145  -0.305  -0.440  -0.570  -0.620
   |
 2 | +0.200  -0.055 [-0.240] -0.360  -0.430  -0.520
   |
 1 | +0.200  -0.050  -0.245  -0.355  -0.460  -0.540
   |
 0 | +0.155  -0.070  -0.240  -0.380  -0.440  -0.500
        0       1       2       3       4       5
    (  5,  5)                              (220,  5)
>>> g29 s1
Now saving the mesh......
SENDING:G29 S1  
Done.
>>> G29 A
SENDING:G29 A
Unified Bed Leveling System v1.01 active
>>> G29 F10.0
SENDING:G29 F10.0
>>> m500
SENDING:M500

Insert in Gcode in print file:

G29 L1
G29 J

Printing test print..... Not close enough to bed
Changing the Probe Offset in LCD from 0.0 down to -0.52
Print again......Printing is not pretty.
Stop print.
Turn off printer.
Turn on printer.

Printer Output Log

SENDING:G29 L1 T
Done.
Bed Topography Report:
    (  5,220)                              (220,220)
        0       1       2       3       4       5
 5 | +0.461  +0.180  -0.057  -0.228  -0.410  -0.541
   |
 4 | +0.496  +0.179  -0.042  -0.174  -0.390  -0.512
   |
 3 | +0.475  +0.178  -0.033  -0.205  -0.346  -0.448
   |
 2 | +0.494  +0.213  -0.034  -0.180  -0.202  -0.443
   |
 1 | +0.418  +0.122  -0.095  -0.271  -0.383  -0.509
   |
 0 | +0.333 [+0.061] -0.170  -0.322  -0.448  -0.555
        0       1       2       3       4       5
    (  5,  5)                              (220,  5)

Now the mesh stored in EEprom is changed? Isn't it supposed to be a stored value, not changed by anything ? Or do I misunderstand something.

tvixen on 8 Oct 2019

check if the m851 z value after changing is restoring after reboot, if not i guess ur eeprom saving is bugged, too.

for my skr mini e3 neither flash nor sd eeprom is working right now...

reloxx13 on 8 Oct 2019

@tvixen let's not confuse UBL and ABL_B. Here the problem is changing the height of the Z axis after the G29 command.
To understand the problem, after G29, send the M114 command and look at the real height of the Z axis.

komandrik on 8 Oct 2019

@tvixen let's not confuse UBL and ABL_B.

Your are right, lets keep things apart.
I will follow the tread closely and if the problem is solved, the UBL problem will probably have been solved too.
There can also be some version conflict. As you probably have version 2.0.x and I'm running 2.1.x-dev.

tvixen on 8 Oct 2019

👍1

@komandrik tried with latest 2.0.x? and is the problem still there?

boelle on 12 Oct 2019

@boelle In the latest version, I got the XY axis jitter when printing. The latest working version is October 03, 2019 and there is still a problem.

komandrik on 12 Oct 2019

@boelle
I hate to say this, but ABL_BILINEAR is still broken in a build pulled today, it only has a less disturbing effects.
Basically, 15 passes of G29 in a row casuses Z offset delta of 0,3mm, so its about 50% of former value.
Not great, not terrible :)
Maybe a rounding issue of some kind?
G29 BILINEAR ABL still bad.txt

salacpavel on 15 Oct 2019

@Roxy-3D @InsanityAutomation @shitcreek what is your take on it? i dont have any issues myself and i think the only difference is that i use a re-arm

boelle on 15 Oct 2019

This lines up with a leveling enable / disable bug I was seeing in tool change by description. I may need to dig more at some point soon.

InsanityAutomation on 15 Oct 2019

@boelle @salacpavel @InsanityAutomation we do not pay attention to changes in the grid readings after each G29. Just look at the Z-axis height readings after the G29 command and be surprised.
Such a problem exists with Mega2560 RAMPS1.4. I think the global problem is in the Marlin firmware.

komandrik on 16 Oct 2019

Have same problem.

aleknest on 16 Oct 2019

@komandrik The thing is I still have to increase Z offset by 0.02 or 0.03 every time I start a new print in order to get 1st layer right, even with this latest build.
And I am experiencing yet another oddity, Z offset value is now zeroed after reset/power cycle with this new build, even when I save it before I switch off. It seems its the Z offset value only one that is not saved/recalled from flash emulated EPROM as other changes are correctly written and recalled.

salacpavel on 18 Oct 2019

After reading this thread I'd like to mention since switching to Marlin 2.0.0 I always power cycle the printer after every print, otherwise I risk the new print not adhering to the bed correctly. This might be another example of this particular problem with z offset.

PS Using Anycubic Kossel Delta with SKR 1.3 + TMC2130 setup (not using G29, only G33)

hapklaar on 19 Oct 2019

👍1

Since this appears to be a difficult one not happening on all printer setups, maybe it does make sense to find out what the affected printers have in common?

I'll give it a start:
Marlin 2.0.bugfix pulled 2days ago

Board:
Ramps 1.4 using RAMPS14_EBF board file

Drivers:
All drivers are set properly in configuration
X, Y TMC2130
Z A4988
Extruder A4988

Probe:
inductive fixed normally open on Z- Limit pin

SD: active but not working properly since I once tried to use SPI

Please let me know if something is missing.

PS: I filed the issue linked above

Louis-Cypher on 26 Oct 2019

Please find in short the behavior I found trying to debug from the linked thread:

Until the first G29 is sent I can move Z by sending G0, G1 or using the Move Axis menu. After sending a G29 Z doesn't move anymore at all (but I can hear that the motors are activated). I can send a G0 Z12 and the only thing happening is that motors are switched on and the Display vlaue changes to Z 12! There is no probing failed message or the like.

Louis-Cypher on 26 Oct 2019

To me it appears that ABL by accident (or on purpose, but doesn't set back to previous values) changes motion parameters of the Z- Axis stepper. This appears to me the only possible reason for the display values changing but the motors not moving. The motors are open loop and obviously the controller does think it moves.

This as well would be a reason why the behaviour only appears on some machines (the ones that are not capable to run the steppers with these settings)

Louis-Cypher on 26 Oct 2019

I changed from ABL_LINEAR to ABL_UBL and the problem of a non moving axis is gone. Printing height is still wrong anf feels pretty random.

Louis-Cypher on 26 Oct 2019

Could some devs _pretty please_ look at this issue and fix it?

salacpavel on 26 Oct 2019

👀1

Build from today. The problem is not fixed. Z axis height still changes after G29
I attach configs from today
Configuration.zip

komandrik on 26 Oct 2019

Knowing the latest build not affected would help as well. I'd need to print a couple of things urgently.

Louis-Cypher on 26 Oct 2019

@Louis-Cypher if your table doesn’t lower, but travels like Prusa’s, it’s easier for you to configure UBL and not start G29, but to register a reference to the table number in the start script.
How to set up UBL many videos on YouTube or the Wiki

komandrik on 26 Oct 2019

After seeing this https://github.com/MarlinFirmware/Marlin/commit/ab0fe1a7dd8cd6bb91174030a86d93dea892319d commit I thought - this could be it! So I gave a try to new build this morning.
The first 5 G29 passes are spot on:

Printer Output Log

_Connecting...
Printer is now online.
G28
SENDING:G28
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.255 +0.148 +0.207 +0.265
 1 +0.065 -0.033 +0.010 +0.010
 2 +0.028 -0.043 +0.035 +0.040
 3 +0.238 +0.067 +0.130 +0.248
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.250 +0.148 +0.205 +0.263
 1 +0.067 -0.030 +0.010 +0.013
 2 +0.028 -0.040 +0.035 +0.043
 3 +0.238 +0.070 +0.130 +0.248
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.253 +0.148 +0.205 +0.263
 1 +0.067 -0.028 +0.013 +0.013
 2 +0.028 -0.040 +0.035 +0.043
 3 +0.235 +0.067 +0.130 +0.248
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.253 +0.148 +0.207 +0.265
 1 +0.067 -0.025 +0.015 +0.015
 2 +0.028 -0.040 +0.038 +0.043
 3 +0.235 +0.067 +0.130 +0.248
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.253 +0.150 +0.207 +0.265
 1 +0.070 -0.025 +0.015 +0.018
 2 +0.028 -0.040 +0.038 +0.043
 3 +0.235 +0.067 +0.130 +0.250_**

But then, its going tits up again. Only this time, Z offset values climb up exponentially, while they were decreasing before):

Printer Output Log

_G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.258 +0.153 +0.212 +0.270
 1 +0.075 -0.020 +0.020 +0.020
 2 +0.030 -0.038 +0.040 +0.048
 3 +0.238 +0.070 +0.135 +0.255
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.263 +0.155 +0.217 +0.275
 1 +0.080 -0.015 +0.025 +0.028
 2 +0.038 -0.033 +0.045 +0.053
 3 +0.243 +0.075 +0.140 +0.260
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.268 +0.160 +0.222 +0.280
 1 +0.085 -0.007 +0.033 +0.035
 2 +0.043 -0.025 +0.053 +0.060
 3 +0.250 +0.082 +0.145 +0.268
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.275 +0.170 +0.230 +0.290
 1 +0.092 +0.000 +0.040 +0.043
 2 +0.050 -0.017 +0.060 +0.067
 3 +0.258 +0.087 +0.153 +0.275
G29 T1
SENDING:G29 T1
Bilinear Leveling Grid:
      0      1      2      3
 0 +0.285 +0.178 +0.238 +0.298
 1 +0.102 +0.008 +0.048 +0.053
 2 +0.060 -0.007 +0.070 +0.075
 3 +0.265 +0.097 +0.160 +0.283_

salacpavel on 27 Oct 2019

@komandrik i assume this is still an issue?

boelle on 3 Nov 2019

Yes, the problem still remains.

komandrik on 3 Nov 2019

my issue bug 15809 might be related ?

hackebike on 7 Nov 2019

I had the same problem since October. At each G29, the print head moved a little further from the bed. After doing some G29 tests over and over again, I noticed a systematic increase in the heights taken during my tests. The augmentation problem is only gone once I erase the EPROM from my board.

On the other hand, other problems with leveling are always present. For some reason that escapes me, if I change the Probe Z offset in the printer, I save the change and reset the printer, I have to change it from 0.30mm or 0.40mm to actually feel that 0.05mm of effect on my bed. In addition, I observe differences between my attempts to G29 which are 10% to 50% of a layer to 0.2mm which is completely out of standard compared to my type of sensor.
I use the same LJ18A3-8-Z / BX for over a year.
I tried to slow down the leveling. but it has no effect on the differences between the G29s. I tried to restart the printer between the G29 too, same thing.

I sincerely believe that the calculation of Z offset and bed leveling is in trouble.

Excuse my english, I use google translation

pfillion42 on 18 Nov 2019

👍1

Maybe one could introduce one final move to the center of the bed after the
G29 moves into the G29 sequence. At this point in time, the tilt and the
warp of the bed is already known. This final move then adjusts the Z-
offset. If that fixes the problem something is wrong in the calculations

Am 18. November 2019 1:45:32 vorm. schrieb pfillion42
notifications@github.com:

I had the same problem since October. At each G29, the print head moved a
little further from the bed. After doing some G29 tests over and over
again, I noticed a systematic increase in the heights taken during my
tests. The augmentation problem is only gone once I erase the EPROM from my
card.
On the other hand, other problems with leveling are always present. For
some reason that escapes me, if I change the Probe Z offset in the printer,
I save the change and reset the printer, I have to change it from 0.30mm or
0.40mm to actually feel that 0.05mm of effect on my bed. In addition, I
observe differences between my attempts to G29 which are 10% to 50% of a
layer to 0.2mm which is completely out of standard compared to my type of
sensor.
I use the same LJ18A3-8-Z / BX for over a year.
I tried to slow down the leveling. but it has no effect on the differences
between the G29s. I tried to restart the printer between the G29 too, same
thing.I sincerely believe that the calculation of Z offset and bed leveling
is in trouble.
Excuse my english, I use google translation
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Louis-Cypher on 18 Nov 2019

@Louis-Cypher previously, the double team G29 saved me. In recent updates, this trick does not work. Today I will try to post a new log of this error.

komandrik on 18 Nov 2019

The augmentation problem is only gone once I erase the EPROM from my board.

you need to do that before each G29? or only after updates?

boelle on 18 Nov 2019

@boelle Just after a Update.
Maybe the problem apeared following an update for the last bugfix from the moment the problem started. Difficult for me to tell you which one. But I continued to test yesterday with several G29s with and without printer reset and I can confirm that the problem of Z height that increases each time is completely gone after the reset of my EPROM. As for the sensor problem, I search the hardware side. I have a SRK 1.3 since the same period and I think it's relative to use the sensor in 5v with this particular board or perhaps a problem of latency on Z_MIN_ENDSTOP_PIN.

pfillion42 on 18 Nov 2019

@pfillion42
I dont think its 5v/latecy issue.
I do G28;G29 and it stays fairly constant relative to the error of the bed level on the homing point and last point (not sure if last).
If I have the bed physically level, I can keep the Z probe offset around 0 (nozzle probe). But If my bed is uneven, I need to adjust the Z probe offset to be some amount near the bed offset relative to the homing position. Marin 1 running on 2560 did not have this problem and I could have my tilted couple mm and it would correct without touching Z offset. Upgrade to Marin 2 on SKR caused this issue and I need to adjust it depending on how uneven the bed is.
I still think there is some wrong offset applied somewhere.

Neverther on 18 Nov 2019

Some reverse engineering of the error. UBL does not use the Z offset,
right? It uses a G28 to adjust Z. Is the integration of UBL around the time
these errors occurred? Then implementation of UBL could have screwed up the
Z adjustment because this has to be adapted, right?

Am 18. November 2019 7:16:37 nachm. schrieb Neverther
notifications@github.com:

@pfillion42
I dont think its 5v/latecy issue.
I do G28;G29 and it stays fairly constant relative to the error of the bed
level on the homing point and last point (not sure if last).
If I have the bed physically level, I can keep the Z probe offset around 0
(nozzle probe). But If my bed is uneven, I need to adjust the Z probe
offset to be some amount near the bed offset relative to the homing
position. Marin 1 running on 2560 did not have this problem and I could
have my tilted couple mm and it would correct without touching Z offset.
Upgrade to Marin 2 on SKR caused this issue and I need to adjust it
depending on how uneven the bed is.
I still think there is some wrong offset applied somewhere.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Louis-Cypher on 18 Nov 2019

Here is a test that I just produced to show you how much the bed leveling can vary from one G29 to another.

Printer Output Log

G28
G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.164 +0.837 +1.247
Recv:  1 +0.189 +0.767 +1.244
Recv:  2 +0.242 +0.898 +1.262
G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.096 +0.812 +1.233
Recv:  1 +0.174 +0.886 +1.221
Recv:  2 +0.193 +0.914 +1.280
G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.165 +0.874 +1.324
Recv:  1 +0.187 +0.913 +1.332
Recv:  2 +0.240 +0.977 +1.229
G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.127 +0.817 +1.204
Recv:  1 +0.142 +0.776 +1.190
Recv:  2 +0.203 +0.892 +1.202

With my config files

Marlin.zip

pfillion42 on 18 Nov 2019

What is strange with your example is that even though you did a G28 all values are bigger than zero which should not be the case if your G28 was done somewhere in the center of your bed. I would expect that some ar lower than zero.

Louis-Cypher on 18 Nov 2019

Here is my result after rebooting the printer:

Printer Output Log

Send: G28
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
Send: M113 S2
Recv: X:146.00 Y:34.00 **Z:11.20** E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.093 -0.023 -0.081 -0.078
Recv:  1 +0.099 +0.026 +0.003 +0.020
Recv:  2 +0.118 +0.081 +0.074 +0.098
Recv:  3 +0.135 +0.112 +0.158 +0.195
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.15** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.095 -0.033 -0.079 -0.076
Recv:  1 +0.102 +0.029 -0.003 +0.003
Recv:  2 +0.121 +0.084 +0.078 +0.090
Recv:  3 +0.138 +0.115 +0.141 +0.188
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.15** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.067 -0.050 -0.107 -0.104
Recv:  1 +0.074 -0.009 -0.033 -0.026
Recv:  2 +0.099 +0.053 +0.047 +0.070
Recv:  3 +0.116 +0.093 +0.119 +0.177
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.17** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.047 -0.070 -0.136 -0.122
Recv:  1 +0.053 -0.020 -0.043 -0.026
Recv:  2 +0.081 +0.034 +0.028 +0.051
Recv:  3 +0.098 +0.074 +0.101 +0.158
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.19** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Below I attach two logs. Simple and advanced. Firmware from 11.17.2019

Marlin.zip

BUG_Log.txt
Log_G28-G29.txt

komandrik on 18 Nov 2019

@Louis-Cypher It's because my G28 is done on x20 y20. It's also the first probing point of G29.

pfillion42 on 19 Nov 2019

Doesn't there exist a "virtual printer" for developers? I think debugging
this on real printers will last for ages because our printers are all
different, inaccuracies of sensors, hysterises of bed springs and the like
make results irreproducable.

Such virtual machine would tell us whether it is a wrong calculation within
minutes. Of course it wouldn't tell us where the error comes from

Am 19. November 2019 5:30:03 vorm. schrieb pfillion42
notifications@github.com:

@Louis-Cypher It's because my G28 is done on x20 y20. It's also the first
probing point of G29.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Louis-Cypher on 19 Nov 2019

Just tu add some weirdenestery. This is the end log of my g28.
and in my config file i ask for "#define Z_AFTER_PROBING 5"
not 4.85mm
On the screen it's 4.85 to...

Recv: deploy: 0
Recv: >>> do_blocking_move_to X47.00 Y20.00 Z2.75
Recv: <<< do_blocking_move_to
Recv: <<< homeaxis(Z)
Recv: <<< home_z_safely
Recv: >>> do_blocking_move_to X47.00 Y20.00 Z5.00
Recv: <<< do_blocking_move_to
[...]
Recv: current_position= X47.00 Y20.00 Z5.00 : sync_plan_position
Recv: current_position= X46.95 Y20.00 Z4.85 : sync_plan_position
Recv: X:46.95 Y:20.00 Z:4.85 E:0.00 Count X:4700 Y:2000 Z:2000
Recv: <<< G28
Recv: ok

Sorry if i bugging you, i just want to help by giving much info as possible

pfillion42 on 19 Nov 2019

@ pfillion42 your g28 is shown after g29. An amendment is made here. If you restart the printer and give g28, Z will be normal. After g29, some correction will be constantly made. So I ask that they remove this amendment.

komandrik on 19 Nov 2019

@Komandrik Thank for the explanation

pfillion42 on 19 Nov 2019

I found the solution to my problem of accuracy.
The censor, a PNP, even if in theory it supports 5v, does not give the same quality of probe as with 12v. I've made a little homemade board for testing my théory, It send 12v in the censor from the plug of my extruder fan and I use a voltage divider to supply the Z min pin. See the difference!

Printer Output Log

Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.035 +0.043 -0.243
Recv:  1 +0.092 +0.102 -0.197
Recv:  2 +0.145 +0.127 -0.165
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.057 +0.057 -0.227
Recv:  1 +0.107 +0.107 -0.175
Recv:  2 +0.160 +0.152 -0.150
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.075 +0.082 -0.203
Recv:  1 +0.125 +0.127 -0.165
Recv:  2 +0.170 +0.170 -0.130
Recv: 
[...]
Recv: M48 Z-Probe Repeatability Test
[...]
Recv: Finished!
Recv: Mean: 0.126750 Min: 0.122 Max: 0.132 Range: 0.010
Recv: Standard Deviation: 0.003544
Recv: 
[...]
Recv: M48 Z-Probe Repeatability Test
[...]
Recv: Finished!
Recv: Mean: 0.125250 Min: 0.120 Max: 0.132 Range: 0.013
Recv: Standard Deviation: 0.003783

I gained x10 accuracy

Here's a Photo

78236591_660990324429016_8938025447774486528_n

pfillion42 on 20 Nov 2019

+1, bilinear leveling just fails (first layer) whatever i do. switched back to linear and bed level is fine again.

got to a point the nozzle printed 2-3 mm over the bed after alot of print restarts caused of bad first layer.

reloxx13 on 20 Nov 2019

I had so much trouble doing tests on this issue and trying to find a patern ...

First of all, the problem is not always present. The printer plays yoyo with me. After several starts without problem, I try to compile a sample of 10x g29 and get the differences in%, everything seems better than I dare to imagine. Im at an average accuracy of 0.37% or 0.0037mm on 10x G29. For me it's more than perfect.

I printed some pieces. I make a new designs to test and put on thingiverse and after 15 prints, Bang !!! It starts again. I can see about 0.01,2,3xx drift after 4 or 5 G29. ans i cannot print anymore (to far from bed) if i do not reset the printer.

I try somehow to reproduce the phenomen this morning and compile some data but I can not do it. the printer is still working well now after 5 complete reset and test.

In addition, trying to reproduce the problem, I discovered another bug or after multiple G28 and G29, only 1 of my 2 Z steppers will activate on a G28 and the next G28 is the other stepper which will activate. I am checking if the bug is already declared in an issue.

I'm starting to think that this is a variable memory allocation error or something that pushes a derivation but permanently once the problem starts during the G29s.

I will try to compile data as soon as the problem returns.

pfillion42 on 23 Nov 2019

A good one!

Printer Output Log

Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 +0.732 +0.980 +0.972
Recv:  1 +0.820 +1.095 +1.027
Recv:  2 +0.850 +1.085 +1.032
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 -1.783 -1.550 -1.570
Recv:  1 -1.725 -1.478 -1.518
Recv:  2 -1.707 -1.460 -1.513
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 -4.310 -4.062 -4.115
Recv:  1 -4.253 -4.023 -4.075
Recv:  2 -4.222 -4.003 -4.070
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 -6.910 -6.677 -6.682
Recv:  1 -6.855 -6.577 -6.630
Recv:  2 -6.807 -6.575 -6.628
Recv: 
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1      2
Recv:  0 -9.435 -9.185 -9.233
Recv:  1 -9.392 -9.122 -9.177
Recv:  2 -9.352 -9.108 -9.163
Recv: 
[...]
Recv: Error:Probing Failed
Changing monitoring state from "Operational" to "Error: Probing Failed"
[...]
Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)"
Connection closed, closing down monitor

pfillion42 on 23 Nov 2019

👀1

@komandrik — Please do the same logging of G29, but do a G28 before every G29.

It is generally recommended to always do G28 before G29. It is also recommended to save the mesh and use M420 S1 rather than G29 for regular printing. Only do G29 when you move the printer.

thinkyhead on 23 Nov 2019

@thinkyhead Thank you for paying attention to the problem. I turned on the printer and sent the G28 & G29 commands sequentially below the terminal output and the full log in the file
P.S. I’m worried about not constant values of the height of the Z axis. I have a Core_XY printer, after turning off the motors, the table falls a little. Therefore, I need to constantly give the G29 command before printing.

Log_G28-G29.txt

Printer Output Log

Send: G28
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
Recv: X:146.00 Y:34.00 **Z:11.20** E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok
Send: M113 S2
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.070 -0.026 -0.073 -0.079
Recv:  1 +0.076 +0.033 +0.009 +0.006
Recv:  2 +0.104 +0.067 +0.070 +0.084
Recv:  3 +0.110 +0.107 +0.144 +0.191
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.16** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G28
Recv: X:146.00 Y:34.00 **Z:11.26** E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.078 -0.009 -0.056 -0.082
Recv:  1 +0.095 +0.031 +0.008 +0.014
Recv:  2 +0.112 +0.074 +0.078 +0.091
Recv:  3 +0.129 +0.115 +0.152 +0.198
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.16** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G28
Recv: X:146.00 Y:34.00 **Z:11.24** E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.074 -0.022 -0.068 -0.085
Recv:  1 +0.081 +0.028 +0.005 +0.002
Recv:  2 +0.099 +0.073 +0.076 +0.079
Recv:  3 +0.116 +0.104 +0.130 +0.188
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.17** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Send: G28
Recv: X:146.00 Y:34.00 **Z:11.25** E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 +0.062 -0.014 -0.060 -0.078
Recv:  1 +0.079 +0.026 +0.003 +0.009
Recv:  2 +0.096 +0.070 +0.073 +0.076
Recv:  3 +0.113 +0.099 +0.136 +0.194
Recv: 
Recv: X:270.00 Y:129.00 **Z:11.16** E:0.00 Count A:63840 B:22560 Z:7224
Recv: ok

Here is my M48 probe test:
Send: M48
Recv: M48 Z-Probe Repeatability Test
Recv: Finished!
Recv: Mean: 0.180000 Min: 0.174 Max: 0.186 Range: 0.012
**Recv: Standard Deviation: 0.003633**
Recv: 
Recv: ok

komandrik on 24 Nov 2019

I am seeing a strange outcome which may be related, @komandrik perhaps you are experiencing the same? Would you mind trying M48 V3 and post your result, notice the Z increases with each probe of M48:

Printer Output Log

Recv: 25 of 40: z: 1.088 mean: 0.6341 sigma: 0.270648 min: 0.183 max: 1.088 range: 0.905
[...]
Recv: 26 of 40: z: 1.125 mean: 0.6530 sigma: 0.281680 min: 0.183 max: 1.125 range: 0.942
[...]
Recv: 27 of 40: z: 1.163 mean: 0.6719 sigma: 0.292682 min: 0.183 max: 1.163 range: 0.979
[...]
Recv: 28 of 40: z: 1.200 mean: 0.6907 sigma: 0.303659 min: 0.183 max: 1.200 range: 1.017
[...]
Recv: 29 of 40: z: 1.226 mean: 0.7092 sigma: 0.313946 min: 0.183 max: 1.226 range: 1.043
...
...
...
Recv: 40 of 40: z: 1.623 mean: 0.9128 sigma: 0.429442 min: 0.183 max: 1.623 range: 1.440
Recv: Finished!
Recv: Mean: 0.912812 Min: 0.183 Max: 1.623 Range: 1.440
Recv: Standard Deviation: 0.429442

Strangely when the M48 is done the probe is not the extra range of Z above the bed.

ReneRebsdorf on 25 Nov 2019

@ReneRebsdorf

Printer Output Log

Send: M48 V3
Recv: M48 Z-Probe Repeatability Test
Recv: Positioning the probe...
Recv: Bed X: 135.000 Y: 105.000 Z: 0.003
Recv: 1 of 10: z: 0.006 mean: 0.0062 sigma: 0.000000 min: 0.006 max: 0.006 range: 0.000
Recv: 2 of 10: z: 0.009 mean: 0.0078 sigma: 0.001550 min: 0.006 max: 0.009 range: 0.003
Recv: 3 of 10: z: 0.002 mean: 0.0057 sigma: 0.003186 min: 0.002 max: 0.009 range: 0.008
Recv: 4 of 10: z: 0.005 mean: 0.0054 sigma: 0.002795 min: 0.002 max: 0.009 range: 0.008
Recv: 5 of 10: z: 0.008 mean: 0.0059 sigma: 0.002667 min: 0.002 max: 0.009 range: 0.008
Recv: 6 of 10: z: 0.009 mean: 0.0065 sigma: 0.002747 min: 0.002 max: 0.009 range: 0.008
Recv: 7 of 10: z: 0.002 mean: 0.0058 sigma: 0.003069 min: 0.002 max: 0.009 range: 0.008
Recv: 8 of 10: z: 0.005 mean: 0.0056 sigma: 0.002894 min: 0.002 max: 0.009 range: 0.008
Recv: 9 of 10: z: 0.008 mean: 0.0059 sigma: 0.002810 min: 0.002 max: 0.009 range: 0.008
Recv: 10 of 10: z: 0.000 mean: 0.0053 sigma: 0.003192 min: 0.000 max: 0.009 range: 0.009
Recv: Finished!
Recv: Mean: 0.005271 Min: 0.000 Max: 0.009 Range: 0.009
Recv: Standard Deviation: 0.003192
Recv: 
Recv: X:146.00 Y:34.00 Z:11.21 E:0.00 Count A:28800 B:17920 Z:7224
Recv: ok

komandrik on 25 Nov 2019

Not the same problem then. Nice probe!

ReneRebsdorf on 25 Nov 2019

👍1

@komandrik since 2.0 was just released a few days ago has this changed this issue at all?

boelle on 7 Dec 2019

I hate to be a dick about it, but really I think devs should really answer this question. We gave as much information and data as we could. Do you agree?

salacpavel on 7 Dec 2019

partly agree, but devs can only answer if they have the same hardware

its 1000 faster if the user do the testing

boelle on 7 Dec 2019

I've got the hardware on a bench. I also haven't had a day off from the day job aside from Thanksgiving in almost 2mo.... Annual crunch leading to the holiday shutdown in automotive.... There are quite a few on the list to get to but they take time like anything else.

InsanityAutomation on 7 Dec 2019

@boellethe problem with the height of the Z axis after the G29 command is present on any printer and is not dependent on electronics. I noticed this problem on Mega2560 RAMPS1.4 and on MKS Gen_L and on 32bit boards.
Anyone can repeat this fault. You need to send the G29 command twice and look at the height of the Z axis after executing the G29 commands.
I have the impression that this problem is not interesting for developers and they do not solve it. The problem has already been open for 2 months and no reaction.
I'm tired of waiting. I switched to Klipper. In klipper there is no such problem. I am disappointed in the support of Marlin and the lack of interest from the developer in solving the problem.

komandrik on 8 Dec 2019

I'm tired of waiting. I switched to Klipper. In klipper there is no such problem. I am disappointed in the support of Marlin and the lack of interest from the developer in solving the problem.

you are perfectly in your right to use klipper, just remember:

marlin is free so you dont pay for it, so you dont have any rights to demand anything
developers work for free so no one can demand that they do anything
being a "dick" and starting to blame the devs for not wanting to solve an issue does make it very
easy for them to skip and issue and find another one in the list
you are very welcome to fix the issue and send in a PR

and yes i use G29 too and i dont have a problem with it, i can run as many G29's i like and the outcome is the same every time: perfect first layer

boelle on 11 Dec 2019

@boelle do not be lazy and run M114, write down the Z axis reading. Then two more times G29 and after each test M114. And write down the height Z each time. Write the result here.
P.S. I do not require developers to execute immediately! I see in the topic only your comments about the changes. Every day I monitored the status of my problem and fix in the main Marlin branch. I do not see changes. How many reviews of people who have the same problem?

komandrik on 11 Dec 2019

👍1

They're spot on for me:
Marlin 2.0.x - SKR 1.3 - BLTouch

Printer Output Log

**G28**
X:178.00 Y:159.00 Z:10.45 E:0.00 Count X:14240 Y:12720 Z:4180

**G29**
Bilinear Leveling Grid:
measured_z = [
 [ +0.218, -0.039, -0.286 ],
 [ +0.151, -0.022, -0.297 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

**G29**
measured_z = [
 [ +0.216, -0.036, -0.282 ],
 [ +0.154, -0.022, -0.302 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

**G29**
measured_z = [
 [ +0.213, -0.048, -0.289 ],
 [ +0.148, -0.024, -0.302 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

**G29**
measured_z = [
 [ +0.240, -0.030, -0.272 ],
 [ +0.168, -0.017, -0.292 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

shitcreek on 19 Jan 2020

@shitcreek could yoo please do 10 G29s in a row and post results?

salacpavel on 20 Jan 2020

Printer Output Log

G28
X:178.00 Y:159.00 Z:10.45 E:0.00 Count X:14240 Y:12720 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.207, -0.030, -0.328 ],
 [ +0.109, -0.035, -0.378 ],
 [ +0.122, -0.036, -0.288 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.197, -0.030, -0.308 ],
 [ +0.117, -0.035, -0.387 ],
 [ +0.130, -0.033, -0.287 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.178, -0.033, -0.306 ],
 [ +0.111, -0.036, -0.387 ],
 [ +0.126, -0.036, -0.291 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.171, -0.039, -0.313 ],
 [ +0.105, -0.044, -0.394 ],
 [ +0.120, -0.042, -0.293 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.165, -0.044, -0.317 ],
 [ +0.098, -0.044, -0.395 ],
 [ +0.115, -0.047, -0.294 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.166, -0.047, -0.320 ],
 [ +0.100, -0.052, -0.392 ],
 [ +0.114, -0.052, -0.294 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.163, -0.054, -0.320 ],
 [ +0.098, -0.052, -0.396 ],
 [ +0.111, -0.060, -0.294 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.162, -0.057, -0.319 ],
 [ +0.094, -0.051, -0.395 ],
 [ +0.108, -0.060, -0.296 ]
];
X:296.00 Y:278.00 Z:10.74 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.159, -0.062, -0.319 ],
 [ +0.095, -0.050, -0.396 ],
 [ +0.106, -0.058, -0.296 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.179, -0.038, -0.317 ],
 [ +0.112, -0.041, -0.387 ],
 [ +0.122, -0.039, -0.287 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.157, -0.061, -0.317 ],
 [ +0.094, -0.045, -0.398 ],
 [ +0.108, -0.060, -0.299 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

G29
Bilinear Leveling Grid:
measured_z = [
 [ +0.158, -0.066, -0.325 ],
 [ +0.090, -0.046, -0.396 ],
 [ +0.105, -0.063, -0.296 ]
];
X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

shitcreek on 20 Jan 2020

Hmm looks promossing! This is with 2.0.1 or later, I assume?

salacpavel on 20 Jan 2020

The build was from 3 days ago.

shitcreek on 20 Jan 2020

@shitcreek I see that you did not understand the essence of the problem. According to your data, after G28, the nozzle height with offset is 10.45mm Offset_Z = -0.45
After the G29 command, the height of the Z axis changes by 10.75mm. Offset_Z became -0.75 The height of the first layer decreases by 0.3mm
I can assume that you have a problem with coating the first layer and skipping the extruder. For printing, you increase the height of the first layer to 150%

komandrik on 20 Jan 2020

Hmm looks promossing! This is with 2.0.1 or later, I assume?

no he use bugfix 2.0.x, that is always newer than 2.0.1 as its updated daily

boelle on 21 Jan 2020

@komandrik btw i use bi-linear too and i get baby smooth first layers

i just adjust my Z offset until i get the first layer like i want, sometimes i have to adjust in steps of 0.05

boelle on 21 Jan 2020

so what i do is

G28 to home all axis
print a 25x25x0.2mm cube
check if Z is to high up (filament lines have gab in them or the nozzle makes track marks)
then i adjust z offset
i do another G29
i repeat test print again

once i have a perfect first layer i save the G29 result to eeprom and i dont do G29 again before my first layers are bad

boelle on 21 Jan 2020

if first layers result change from print to print then something is wrong, endstop not solid or something like that

boelle on 21 Jan 2020

@boelle I have a hypercube. The table lowers and rises. The prints are even and I have no complaints about the mechanics.
In the documentation for Marlin there is an instruction on how to set offset Z correctly. I did everything according to the instructions. The accuracy of the probe is 0.003mm. In print, I use different types of plastics. To do this, you need a different table temperature. My table has different curvatures at different temperatures. Therefore, I give the G29 command before each print and wait for the correct operation from the firmware. Instead, we observe for each user a change in the height of the Z axis after the G29 command. Those users whose axis height changes upwards do not feel the problem with poor adhesion of the first layer, since they, in fact, the first layer is reduced. Those users whose height changes in a smaller direction are experiencing a problem like mine. Very high first layer. This causes the part to lag behind the table during printing.
If the firmware and offset Z are configured according to the instructions, then when printing the first layer with a height of 0.2 mm, we should get exactly 0.2 mm plastic layer. Not 0.1, not 0.15, not 0.3, but 0.2 mm!
From your post above, I see the same problem with which you are struggling with the selection method, which means that you ignore the instructions and firmware rules.
I'm tired of repeating the same thing in every answer. Maybe the Google translator does not correctly convey my thoughts and my conclusions to you. I dont know.

komandrik on 21 Jan 2020

i dont struggle at all, its quite simple for me to understand

i did not even have to read any documentation to make it work for me

boelle on 21 Jan 2020

It looks like the issue was traced back to having RESTORE_LEVELING_AFTER_G28 enabled in the firmware. Just wondering if everyone who reported the issue here has it enabled? I'm having the same issue, and can confirm mine is enabled in latest 2.0.x. I'll try changing it after work today and see if the issue persists.

The-slunk on 22 Jan 2020

RESTORE_LEVELING_AFTER_G28 included

komandrik on 22 Jan 2020

mine is also enabled, no issues

boelle on 22 Jan 2020

mine is also enabled, no issues

I meant for those who are having the issue, to check if the setting is defined. Sorry for the randomness/confusion, my reply wasn't aimed towards finding the root cause so much as it was towards finding a way to alleviate the issue for the time being.
Any way to narrow down the issue seems like a plus at the moment.

Edit: I've reviewed the config files from the duplicate issues, and don't see a consistent RESTORE_LEVELING_AFTER_G28 so I'm scrapping that. Only consistent thing I can find between the files is ENABLE_LEVELING_FADE_HEIGHT so I'll play with that after work. Otherwise, I'm giving up on digging through the configs and will wait for someone smarter than myself to dig through the leveling libraries.

The-slunk on 22 Jan 2020

👍1

So it seems like my issue slightly differs from @komandrik in that his Z position would change after the G29 command, and mine would change after every G28 command. I first started going through terminal commands to reproduce the original issue with my Firmware unchanged:

#define EXTRAPOLATE_BEYOND_GRID
#define RESTORE_LEVELING_AFTER_G28
//#define ENABLE_LEVELING_FADE_HEIGHT

Printer Output Log

Send: G28
Recv: X:158.00 Y:93.00 Z:5.00 E:0.00 Count X:6320 Y:3720 Z:2000

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.677 -0.486 -0.366 -0.359 -0.449
Recv:  1 -0.404 -0.269 -0.199 -0.193 -0.231
Recv:  2 -0.184 -0.127 -0.093 -0.092 -0.107
Recv:  3 -0.104 -0.057 -0.026 -0.031 -0.033
Recv:  4 -0.056 -0.003 +0.022 -0.005 -0.060
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1962

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.693 -0.511 -0.392 -0.390 -0.471
Recv:  1 -0.435 -0.310 -0.244 -0.238 -0.270
Recv:  2 -0.211 -0.152 -0.116 -0.114 -0.126
Recv:  3 -0.124 -0.084 -0.058 -0.059 -0.055
Recv:  4 -0.064 -0.023 -0.002 -0.027 -0.072
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1962

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.722 -0.546 -0.430 -0.422 -0.495
Recv:  1 -0.479 -0.352 -0.286 -0.277 -0.307
Recv:  2 -0.248 -0.187 -0.150 -0.145 -0.153
Recv:  3 -0.151 -0.111 -0.083 -0.082 -0.081
Recv:  4 -0.092 -0.047 -0.027 -0.048 -0.095
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1959

Homed X:
Recv: X:0.00 Y:185.00 Z:4.99 E:0.00 Count X:0 Y:7400 Z:1950
Homed Y:
Recv: X:0.00 Y:-29.00 Z:5.85 E:0.00 Count X:0 Y:-1160 Z:1950
Homed X (again):
Recv: X:0.00 Y:-29.00 Z:5.85 E:0.00 Count X:0 Y:-1160 Z:1950

Send: G28
Recv: X:158.00 Y:93.00 Z:5.17 E:0.00 Count X:6320 Y:3720 Z:2000

(Z value changed after running G28 again)

Re-load Firmware (2.0.x) with the following commented:

//#define EXTRAPOLATE_BEYOND_GRID
//#define RESTORE_LEVELING_AFTER_G28
//#define ENABLE_LEVELING_FADE_HEIGHT (I believe I had this off initially anyway)

followed by an M502 and M500 command just for good measure. Then repeated steps to reproduce issue:

Printer Output Log

Send: G28
Recv: X:158.00 Y:93.00 Z:5.00 E:0.00 Count X:6320 Y:3720 Z:2000

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.637 -0.443 -0.328 -0.345 -0.461
Recv:  1 -0.364 -0.231 -0.171 -0.198 -0.257
Recv:  2 -0.136 -0.077 -0.044 -0.068 -0.108
Recv:  3 -0.043 -0.006 +0.017 -0.013 -0.041
Recv:  4 +0.012 +0.050 +0.060 +0.002 -0.072
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1973

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.655 -0.471 -0.361 -0.373 -0.464
Recv:  1 -0.393 -0.268 -0.212 -0.231 -0.280
Recv:  2 -0.168 -0.107 -0.073 -0.096 -0.126
Recv:  3 -0.062 -0.026 -0.002 -0.032 -0.053
Recv:  4 -0.012 +0.031 +0.045 -0.011 -0.076
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1973

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.668 -0.488 -0.383 -0.393 -0.479
Recv:  1 -0.408 -0.290 -0.237 -0.256 -0.299
Recv:  2 -0.182 -0.126 -0.097 -0.118 -0.144
Recv:  3 -0.079 -0.048 -0.032 -0.058 -0.073
Recv:  4 -0.021 +0.017 +0.025 -0.031 -0.093
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1971

Homed X:
Recv: X:0.00 Y:185.00 Z:4.91 E:0.00 Count X:0 Y:7400 Z:1964
Homed Y:
Recv: X:0.00 Y:-29.00 Z:4.91 E:0.00 Count X:0 Y:-1160 Z:1964
Homed X (again):
Recv: X:0.00 Y:-29.00 Z:4.91 E:0.00 Count X:0 Y:-1160 Z:1964

Send: G28
Recv: X:158.00 Y:93.00 Z:5.00 E:0.00 Count X:6320 Y:3720 Z:2000

Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 -0.595 -0.440 -0.340 -0.353 -0.437
Recv:  1 -0.358 -0.251 -0.198 -0.211 -0.250
Recv:  2 -0.151 -0.106 -0.078 -0.095 -0.116
Recv:  3 -0.058 -0.032 -0.012 -0.032 -0.041
Recv:  4 +0.001 +0.023 +0.029 -0.016 -0.069
Recv: 
Recv: X:235.00 Y:185.00 Z:5.00 E:0.00 Count X:9400 Y:7400 Z:1964

So it seems like the issue I had (G28 to home, then adjust Z offset, then G28 again to see that .1mm to .3mm was added to Z pos.) is related to RESTORE_LEVELING_AFTER_G28, whereas the issue of Z pos changing after every G29 command may be related to ENABLE_LEVELING_FADE_HEIGHT since I had that disabled and did not see varying Z position even in my initial attempt to reproduce the output komandrik was seeing.

I'll try printing something now to see if I get a decent first layer and report back.

Edit: still getting adhesion problems printing from SD, but I got something going well with Octoprint. I did use a raft due to my patience running out , but FWIW the raft lines went down perfectly. Kind of a roundabout way of doing it, but I'll test more tomorrow after work.

The-slunk on 23 Jan 2020

👍1

i had, past tense, problem, after G29 i have Z in 5mm more than i desired, and was ,,printing,, in air.
how i solve this ? reduced Z - offset in firmware to 0, and in slicer i settet it to mine -0.3mm. if i try to use anything more than -0.7 no change. I had previosly looong time ago on 1.1.9 marlin, solved with re configuring firmware too. My setup, TMC2130, sw spi, no fancy stuff, only silent mode and hybrid treshold, MKS SGEN L., induction fixed probe to Z min
after re configuring in firmware (downloaded i think second week of 2020) to Z offset 0, no problems.
My before print : G28, waiting for bed heated, G29, print

flankerzo on 23 Jan 2020

@flankerzo it's called a crutch. These are not our methods. The firmware should work correctly.
@ The-Force disabling #define ENABLE_LEVELING_FADE_HEIGHT will distort the print geometry.

komandrik on 23 Jan 2020

@flankerzo it's called a crutch. These are not our methods. The firmware should work correctly.
@ The-Force disabling #define ENABLE_LEVELING_FADE_HEIGHT will distort the print geometry.

Quite the opposite actually. If the bed is tilted, that on will distort what would have been fine. If it's warped and bulged, the base is distorted regardless but it smooths it before it gets to the top.

InsanityAutomation on 23 Jan 2020

@flankerzo it's called a crutch. These are not our methods. The firmware should work correctly.
@ The-Force disabling #define ENABLE_LEVELING_FADE_HEIGHT will distort the print geometry.

I figured that, but that's a price I'm willing to pay in order to print at all haha. And agreed, in a perfect world it would work flawlessly but I don't have the knowledge to fix it and I hate wasting time getting upset at something I can do nothing about. Hence putting time into finding a roundabout way to make it work in the meantime. It's a free firmware after all so if I can just get it to work consistently I'll be happy. And if I can help someone else get it working that's a big plus. I'm gonna try a few more settings today after work.

The-slunk on 23 Jan 2020

I've similar issue with AUTO_BED_LEVELING_BILINEAR
Each time I launch a print when the G29 command ends my nozzle is always above the plate by about 0.5mm
So i tried this with pronterface to set z-offset

Perform the origin of the printer axes via G28
M851 Z0 - Initialize the offset in Z to 0 (reset to Z of the Zoffset if there was one)
M500 - Store this setting in EEPROM
~~M501 - Retrieve the parameters from the EEPROM to make them active~~
M503 - Display the current parameters to verify that they have been taken into account
G28 Z - Originating the Z axis
G1 F60 Z0 - Move the nozzle to Z0
M211 S0 - Deactivate the limit switches (to be able to go below 0)
Slowly descend (0.01mm step) the Z axis until rubbing the sheet of paper (or the shim used)
Note the displayed value of the position of the Z on the screen of the box (add this value (without taking the negative sign into account) to the thickness of the shim used)
M851 Zx.xx (x.xx being the offset in Z calculated in point 10 (negative value))
M211 S1 - Reactivate the limits of the limit switches
M500 - Save settings in EEPROM
~~M501 - Retrieve the parameters from the EEPROM to make them active~~
M503 - Check one last time that everything has been taken into account

I launch a print and my first layer sticks well.
But i think FW is bugged, because i must able to do same thing from LCD menu

kramer04 on 23 Jan 2020

@komandrik My Z homing is in the middle of the bed and so the G28 returns the coordinates for the middle:

X:178.00 Y:159.00 Z:10.45 E:0.00 Count X:14240 Y:12720 Z:4180

G29 returns the last probe point's coordinates which in my case is back right corner:

X:296.00 Y:278.00 Z:10.75 E:0.00 Count X:23680 Y:22240 Z:4180

Note the different X and Y coordinates.

If you compared all my G29 results, Z's only gone up by 0.01 - this is negligible in my case and was probably due to me fidgeting with the machine.

I print with 100% first layer and if I get the Z offset dialed in, I can expect good consistent adhesion print after print. And I am using 2.0.1 for this one, not bugfix - I normally use bugfix though.

Also, bed leveling is off on startup and thus G28 would return the unleveled Z height. If I turned on bed leveling M420 S1 before homing, I'd get the leveled Z height.

shitcreek on 23 Jan 2020

that is how i do it, RESTORE_LEVELING_AFTER_G28 enabled

home all
G29
Save to eeprom

then at start of every print

M420 S1
home all

boelle on 24 Jan 2020

I have the same issue and i dont know how to resolve it please can you help i let here my log you can se how the grid measures increase in every g29 Example:

Printer Output Log

Recv:       0      1      2
Recv:  0 -0.027 -0.067 -0.130
Recv:  1 -0.027 -0.056 -0.119
Recv:  2 -0.026 -0.053 -0.140

Recv:       0      1      2
Recv:  0 +0.043 +0.018 -0.052
Recv:  1 +0.050 +0.028 -0.044
Recv:  2 +0.053 +0.013 -0.080

Recv:       0      1      2
Recv:  0 +0.150 +0.123 +0.056
Recv:  1 +0.158 +0.133 +0.065
Recv:  2 +0.158 +0.128 +0.041

i am in latest bugfix (29-01-2020) with an SKR E3 Mini 1.2
Probe EZABL
Standar Deviation: 0.001350

My Config Files
Config Files.zip
My Log
6 Bed Levels.txt

sismo99 on 30 Jan 2020

Hi everyone,
I do have this same issue on my Prusa clone. I am running skr 1.3 with marlin 2.0. I have tried 2.0.1/2.0.2/2.0.3/bugfix-2.0.x. All of them give the same result. I need to babystep adjust the z offset at the beginning of all prints. This is quite annoying because I need to spend 10 mins waiting for the printer to run all the leveling and adjust the Z. I do have a Ender 3 Pro and it does not have this issue. It gives me the confident that I just need to press start print and leave. I do not need to worry about adjusting anything. The only difference between my Ender 3 Pro and Prusa clone is that Prusa clone is equipped with a probe as a z min endstop. I am guessing the probe is affected by heat/magnet and gives different value every time it probes. Z Home position changes every time it do a G28. Please let me know if you have any ideas. Definitely need some help. Appreciated.
here is my start of gcode

g28
g29
m500
m420 s1

ymanyin on 5 Feb 2020

Reporting back after 2 weeks of printing with ENABLE_LEVELING_FADE_HEIGHT and RESTORE_LEVELING_AFTER_G28 both commented out. First layers have been consistently good, and actually the best I've printed with, to the point where I've not had to monitor first layer at all. To be honest this is actually the most confident I've been walking away after starting a print but YMMV. And getting no skewing of prints with ENABLE_LEVELING_FADE_HEIGHT commented either, but that may be more dependent on how warped ones bed is.

The-slunk on 5 Feb 2020

Reporting back after 2 weeks of printing with ENABLE_LEVELING_FADE_HEIGHT and RESTORE_LEVELING_AFTER_G28 both commented out. First layers have been consistently good, and actually the best I've printed with, to the point where I've not had to monitor first layer at all. To be honest this is actually the most confident I've been walking away after starting a print but YMMV. And getting no skewing of prints with ENABLE_LEVELING_FADE_HEIGHT commented either, but that may be more dependent on how warped ones bed is.

Thanks for the result man. I am gonna try your method but one quick question: Do you do a M420 S1 before G28 or after G29?

ymanyin on 6 Feb 2020

Quite the opposite actually. If the bed is tilted…

It is still better to use fade. Bilinear interpolation will keep that Z axis moving up and down throughout the print, and that will tend to introduce artifacts. Mesh leveling is not a good way to deal with a tilted bed. For pronounced tilt you are better off with a matrix like you get from the LINEAR version of bed leveling, which will tilt the whole model. Bilinear mesh on a tilted bed will give you a trapezoidal distortion.

thinkyhead on 6 Feb 2020

Thanks for your reports @The-slunk. You are maybe the one individual in this thread who _tried things_ and brought us real data to show that some things had effects. I suspect that some interaction between Z fade and certain meshes may be involved, but truly I am not certain. I'm going to take your example as inspiration and try different combinations of settings to see if I can force the issue to appear.

I do know that if you do several G29 passes on a heated bed while it is heating up, they will tend to differ by a lot, so I hope that this is not throwing some people off.

thinkyhead on 6 Feb 2020

Reporting back after 2 weeks of printing with ENABLE_LEVELING_FADE_HEIGHT and RESTORE_LEVELING_AFTER_G28 both commented out. First layers have been consistently good, and actually the best I've printed with, to the point where I've not had to monitor first layer at all. To be honest this is actually the most confident I've been walking away after starting a print but YMMV. And getting no skewing of prints with ENABLE_LEVELING_FADE_HEIGHT commented either, but that may be more dependent on how warped ones bed is.

Thanks for the result man. I am gonna try your method but one quick question: Do you do a M420 S1 before G28 or after G29?

I do not, I use bilinear and assumed it was enabled when G29 runs. I use it it my start G-code per print.

And @thinkyhead I believe this issue was in the actual z-offset changing after G28/G29 commands, which would of course change the mesh points as well.

EDIT: I always waited for my bed to heat up fully between the G28/G29 commands while testing, if that helps

The-slunk on 6 Feb 2020

@thinkyhead thanks for the answer. I opened a request with a change in the height of the Z axis after measuring the bed with the G29 command. I see a problem in the height measurement algorithm used. Disabling all kinds of settings, and especially the height of the termination of the alignment cannot affect the measurement before printing.
I am not good at programming and cannot figure out the code. I understand the automatic alignment algorithm as follows:

G28 - find the base reference point Offset_Z.
G29 - the height is measured at each measuring point relative to the base.
Start printing from (base height - offset_Z) - (grid height measurement)
I have a problem after completing step 2. My base height offset_Z is changed before printing starts. Moreover, the base height becomes less than the original. When offset_Z is added, the first layer is printed higher than it should be. This leads to poor adhesion of the first layer.
Those who have a base height of offset_Z change more are more fortunate. They have the first layer “smeared” into the table and they don’t even notice this problem.
Maybe the essence of my request and problem will be clearer.

komandrik on 6 Feb 2020

To put it more concisely:

G28 Z establishes Z0.
G29 measures Z offsets relative to that Z0
- (Dependent on a good M851 Z setting.)

thinkyhead on 6 Feb 2020

@The-slunk — I am able to reproduce the issue so I should be able to track it down with the addition of logging in all the right places. I'm in the process of setting up Octoprint so my lazy coder butt can sit tight and flash new firmware from the comfort of my cyber pod, and then I'll get on with solving this conundrum.

thinkyhead on 6 Feb 2020

@thinkyhead
Снимок экрана20200206132601

komandrik on 6 Feb 2020

@thinkyhead

Good call on the picture outlining the issue, I'll throw mine in too for @thinkyhead to see. Again, this was before disabling fade height and g28 restores ABL were commented out.

Screenshot_20200206-070013~2

The-slunk on 6 Feb 2020

@komandrik, @The-slunk — Pretend I have enough brains to have seen that already.

I don't know how many ways I can explain to you all that the current Z value is _supposed to change_ when you enable or disable leveling.

thinkyhead on 6 Feb 2020

@komandrik, @The-slunk — Pretend I have enough brains to have seen that already.

I don't know how many ways I can explain to you all that the current Z value is _supposed to change_ when you enable or disable leveling.

That explains why disabling G28 ABL restore solved my issue. The problem is that when setting my z-offset, running G28 again to check my offset, it would show different z value. Which in turn I would adjust offset to, and so on. By the time I started printing I would either be crashing into the build plate or printing mid air.... If that makes sense.

Edit: I was giving it some thought on the drive home from work and I understand why you would want G28 to enable ABL, but would there be a way (or a use, rather) to reset the plane height before every G28 command if you have the option set in firmware to activate ABL with G28? Just trying to think of a way to prevent other novice users from making the same mistake I did (settings Z offset based on the changing height rather than the true distance of nozzle to surface).

The-slunk on 6 Feb 2020

@The-slunk Sorry, if I ask about this issue again, but I have exactly the same problem and I am trying to navigate this thread for a solution. Like many others, I am using G28 followed by G29 and then start the print from SD card. My Z-Offset is all over the place ...sometimes crashing the nozzle, sometimes air printing. Adjusting z-offset while printing and saving to EEPROM is not helping. (Why it did work on my old Ender 3 pro is beyond me today).

Has disabling ENABLE_LEVELING_FADE_HEIGHT and RESTORE_LEVELING_AFTER_G28 solved the situation for your for good, or did you adjust your starting gcode and/or Z-offset calibration in another way?

Thanks a bunch !!

Alphaelectric on 4 Mar 2020

@The-slunk Sorry, if I ask about this issue again, but I have exactly the same problem and I am trying to navigate this thread for a solution. Like many others, I am using G28 followed by G29 and then start the print from SD card. My Z-Offset is all over the place ...sometimes crashing the nozzle, sometimes air printing. Adjusting z-offset while printing and saving to EEPROM is not helping. (Why it did work on my old Ender 3 pro is beyond me today).

Has disabling ENABLE_LEVELING_FADE_HEIGHT and RESTORE_LEVELING_AFTER_G28 solved the situation for your for good, or did you adjust your starting gcode and/or Z-offset calibration in another way?

Thanks a bunch !!

Hey! Well I narrowed my specific issue down to RESTORE_LEVELING_AFTER_G28 so I believe mine was slightly different from the original post, or at least a different flavor of it. I would set my Z offset based on my G28 command, and then check it by performing another G28 command. When i did that, the actual height of my probe offset would change (see my testing) which @thinkyhead confirmed was expected behavior when ABL is enabled. However, I would in turn continue setting my Z offset to the adjusted value resulting in a false offset by the continuous change. Disabling RESTORE_LEVELING_AFTER_G28 resolved this issue for me.

However, what you're describing doesn't sound like the same problem if your z offset is changing throughout the build surface. Did you make sure to adjust your probe offset (from the nozzle)? If your z offset is correct from the center of the bed, it should continue to plot out correctly throughout your surface.

The-slunk on 5 Mar 2020

Funny enough, same issue can be obsever with ABL_LINEAR on bigger prints.
I do not know what changed between 1.X and 2.X and why it takes so long to resolve.

salacpavel on 5 Mar 2020

@The-slunk It's just like you explained. My Z-offset is not changing throughout my surface but consecutively from the start from each print to the next, regardless if I power cycle in between.
My next step is to perform just what you did:

G28
Bring nozzle down to "0" with regular Move-Z command
Adjust z-offset to paper level with babysteps
Save this z-offset
Start a print with G28, G29, prime line and so forth....

I hope that this will lead to a more consistent first layer experience. If it's still all over the place after that, then I'm out of ideas.

Alphaelectric on 5 Mar 2020

I've done a lot of logging and trying to understand where and why the discrepancies arise, but it will require another 20-30 hours of sustained effort to solve this issue. In the meantime just keep using the workarounds.

thinkyhead on 7 Mar 2020

👍3

I can definitely confirm that bilinear ABL is broken in its current form. I have performed offset-calibration as lined out by @The-slunk (see my last post). It is not possible to print twice with the same Z-offset.

M48 on my probe returned 0.011855

The issue is the same regardless if probing 2 times with regular speed or 3 times really slow.

I am unable to do the mesh comparison that @The-slunk did, but I can observe that the Z-rod moves in areas where there is almost no deviation in the bed surface and at other times when you have deviations, it doesn't move at all. Almost like the mesh is not placed where it is supposed to be.

Specs: BTT E3 Dip 1.0, BLTouch v3.1, TMC2208

Alphaelectric on 7 Mar 2020

😕1

@thinkyhead

I've done a lot of logging and trying to understand where and why the discrepancies arise, but it will require another 20-30 hours of sustained effort to solve this issue. In the meantime just keep using the workarounds.

HI thinkyhead. Any progress with this issue? Thanks.

Andychud on 15 Mar 2020

I’m wondering if the issues in this bug are related to #17166. It was causing me to have very similar problems. A fix for it was just merged in both 1.1.x and 2.0.x bugfix branches.

interstellarmisfit on 16 Mar 2020

@interstellarmisfit

I’m wondering if the issues in this bug are related to #17166. It was causing me to have very similar problems. A fix for it was just merged in both 1.1.x and 2.0.x bugfix branches.

I'm not sure it is. I have been monitoring this and your own threads to keep myself abreast of the progress because I'm experiencing the same issues. After compiling the latest by bugfix that includes your fix i think it's still broken.
I've got two issues going on. One is with the z height after probing that reflects the issues discussed here, which hasn't been fixed with the latest bugfix, and, an issue where the front right of the print has a lower z height than the back left. It's like the bilinear leveling isn't being applied. It doesn't matter where where the model is placed and isn't limited to the size of the model.

Lastly! In succeeding prints the z height seems to be cumulatively adding to the first print. On my second print, after a successful print, the nozzle starts printing higher than where it should be causing the first layer to be completely off the build plate. Thanks for working hard to fix these problems!

AFprinter on 16 Mar 2020

to tempararly fix my issue, i have removed my skr 1.3 from my ender 3 and reinstalled my mkg gen l running 1.1.9 and it has been working since except with the annoying temperature fluxuation issue that is known to happen with this board. i did this for a couple reasons, i really needed the printer and also to make sure that it was not a problem related to the gantry or other hardware. as soon as this issue is remedied i and going to reinstall the skr and uplaoad the update.

rmitchell80 on 30 Mar 2020

Wauu that ABL thing must really have been bugging you. Very dramatic move.

tvixen on 30 Mar 2020

i figured that i needed the printer working and i had the parts laying around and i got tired of fiddeling aroung with the z offset

rmitchell80 on 31 Mar 2020

👍2

Frankly, I would do the same, if I was not stuck with STM32 board as I blew up original one.

Anyway, seeing the last fix in bi-linear ABL, I have switched back from linear and now my 1st level is almost perfect. However as others, I still have to tune Z offset with every print, even thought I do not do G29 with every print , just G28 and re- use ABL values from memory.
I have started with Z offset -1.47 a week ago, now I am at -1.25 after maybe 20 prints.
Indeed it is very annoying as I have to attend every print from the start..

salacpavel on 31 Mar 2020

Uninstalling BLTouch and reverting to manual leveling solved it for me....can finally leave the printer alone again after starting the print...

Alphaelectric on 31 Mar 2020

Frankly, I would do the same, if I was not stuck with STM32 board as I blew up original one.

Anyway, seeing the last fix in bi-linear ABL, I have switched back from linear and now my 1st level is almost perfect. However as others, I still have to tune Z offset with every print, even thought I do not do G29 with every print , just G28 and re- use ABL values from memory.
I have started with Z offset -1.47 a week ago, now I am at -1.25 after maybe 20 prints.
Indeed it is very annoying as I have to attend every print from the start..

Are you setting your z offset in firmware or in the menu/command? I leave mine on 0 in the firmware and set it from my menu. Haven't had an issue with my z offset since turning off "enable ABL after G28"

The-slunk on 31 Mar 2020

Any progress on this?

Grogyan on 1 Apr 2020

i have tried both ways of setting the z offset. i havent tried the linear abl, but i also have different build plates that i use depending on what im printing

rmitchell80 on 2 Apr 2020

i have tried both ways of setting the z offset. i havent tried the linear abl, but i also have different build plates that i use depending on what im printing

I've strictly used bilinear ABL which is what I had the issue on, and I've resolved it. I can share my config file, but it's pretty customized for my ender 3 using the SKR mini E3 1.0 on linear rails with a Hemera extruder and the EZAbl pro mini. Maybe you can just compare the ABL section? Let me know and I'll share it if you think it could help.

The-slunk on 3 Apr 2020

i can try that

rmitchell80 on 7 Apr 2020

Has there been any progress on this?

I haven't been able to do any printing due to this.

Grogyan on 13 Apr 2020

Has anyone tried ABL (non-bilinear) if the problem exists?

iammenotyou on 16 Apr 2020

ABL linear is unaffected by this issue (whatever the cause is).

salacpavel on 19 Apr 2020

i have tried both ways of setting the z offset. i havent tried the linear abl, but i also have different build plates that i use depending on what im printing

I've strictly used bilinear ABL which is what I had the issue on, and I've resolved it. I can share my config file, but it's pretty customized for my ender 3 using the SKR mini E3 1.0 on linear rails with a Hemera extruder and the EZAbl pro mini. Maybe you can just compare the ABL section? Let me know and I'll share it if you think it could help.

Would you share your config? I'm curious to see the differences and if I can resolve this issue myself. I have the same problem, obviously (SKR Mini E3 1.2 board, EZABL). I have to adjust the Z every print.

Ixian on 19 May 2020

Same, would like to compare my configs with a working one, I am on a SKR Pro.
thx

hackebike on 19 May 2020

im currently using my mks gen L running 1.1.9, i havent tried running my skr again cause of this. i would like to compare one that works as well. like mentioned above i use different build plates depending on what im printing and the meshes for each are saved in eeprom so i am stuck using my gen L again.

rmitchell80 on 20 May 2020

Hi, I have also experienced this for both my SKR 1.4 and 1.4 Turbo. After fiddling with it on an off for weeks I still had not managed to complete one successful print with ABL_BILENEAR. (I'm using a PL-08N fyi).
Because of this issue I've moved to Klipper and the very first print (which I configured to use ABL) came out perfect leveled first layer and I have a VERY warped bed. So basically I am saying it's not a hardware issue. I'm sure it will eventually be fixed by the Marlin team who do a great job but just so other users who are experiencing the same and need a quickish solution to this issue.

JeffMedd on 21 May 2020

👍1

Hi, I have also experienced this for both my SKR 1.4 and 1.4 Turbo. After fiddling with it on an off for weeks I still had not managed to complete one successful print with ABL_BILENEAR. (I'm using a PL-08N fyi).
Because of this issue I've moved to Klipper and the very first print (which I configured to use ABL) came out perfect leveled first layer and I have a VERY warped bed. So basically I am saying it's not a hardware issue. I'm sure it will eventually be fixed by the Marlin team who do a great job but just so other users who are experiencing the same and need a quickish solution to this issue.

Even assuming one is already using Octoprint going from Marlin to Klipper to fix this is hardly what I would call a "quickish" solution, unless you were already set up and switching between both. Anyway that doesn't solve the problem with Marlin.

This may hinge on the extended memory/memory corruption issue, given that for myself and others here the problem does not occur if you power cycle in between prints (that is to say my mesh/z-step stays the same and my prints and first layers come out fine, but only if I turn of the printer after each print. If I print, then launch another print, the Z offset isn't used, same issue reported here and elsewhere).

Is everyone doing the _512k builds for their SKR boards I assume?

Ixian on 21 May 2020

I have assembled 4 large printers. The firmware is the same. The print area is 1m * 1m * 1m. Two work on 8-bit electronics, everything is fine there. Two others on RURAMPS 1.3. On them just this problem. But because of the size, the first layer prints normally. Here are just the models obtained above. The model is 190 mm high, it turns out 196 mm. With increasing height, the size also grows. If you simply raise along Z, the size does not change. Only with auto level enabled and XY navigation.
Turning the printer off and on does not affect the result.
And babystep does not work for them, depending on the coordinate, when you turn the encoder, it either only rises along Z, or only falls.
I installed the latest firmware for the test, too.
Sorry for google translator.

StrannikZet on 25 May 2020

Funny observation. I have recently re-enabled b-ABL on my STM32 based E3 printer to see what progress on this issue has been made so far. BUT I have not enabled restore of bed leveling data after G29 in config, as well as I do not enable them with M420 S1, nor I do G29 in start g-code any more.
So basically, I have a printer with b-ABL enabled, but I do not use ABL data for print. I have simply leveled the bed manually (sheet paper method).
EVEN SO, I STILL NEED TO POWER CYCLE THE PRINTER BETWEEN PRINTS OTHERWISE I AM FORCED TO ADJUST Z OFFSET BEFORE EVERY PRINT TO GET THE 1ST LEVEL RIGHT.

salacpavel on 25 May 2020

Looking back at my last entry from March 7th, nothing has changed. B-ABL is still broken and I'm glad I had an older firmware version around with no ABL. So back to the basics works.

I have since seen dozens of people running into the same problem in a variety of 3D printing groups, be it for printers, firmware or probes. None of them have gotten any further with their projects.

Which brings me to question the real necessity/relevance of ABL.

3D printing is still growing world wide
b-ABL - THE most common ABL - remains broken in Marlin 2
many, many people run into the same wall (very few take to Github for help)

This leaves room for two very likely conclusions:

people eventually give up and continue without ABL (especially those with silent driver boards)
ABL is too complicated and not worth fixing in its current state on a time/effort/benefit equation

Alphaelectric on 25 May 2020

anyone starting feel that this issue is being thrown by the wayside?

rmitchell80 on 26 May 2020

👍3

I have been following this for about 2 weeks now.. I'm on an Ender 5 w/ a SKR E3 Mini (also tried an SKR E3 DIP w/ 2208's and the th3d ezboard, its not hardware..) I am having all of the same issues you are all having. My printer is 100% unusable right now. Really starting to wonder when someone with the knowledge to do something about this will step in and help..

txt4nk on 27 May 2020

I have been following this for about 2 weeks now.. I'm on an Ender 5 w/ a SKR E3 Mini (also tried an SKR E3 DIP w/ 2208's and the th3d ezboard, its not hardware..) I am having all of the same issues you are all having. My printer is 100% unusable right now. Really starting to wonder when someone with the knowledge to do something about this will step in and help..

This just answered one of my qeustions if this was just a problem with these boards. the only way that i know to fix it is to either use manual bed leveling or if there is a way to load a older version (1.1.9) onto the board but i dont think that the board would run it. i ended up going back to my mks gen l board and loading marlin 1.1.9 on it. nice thing was is that i just had to switch 2 wires on the the bltouch and transfer the drivers over to the other board. I have even cosidered using klipper or repiter

rmitchell80 on 28 May 2020

Based on the reports I've seen it seems that this issue is mostly affecting the TMC 2208 based boards. Also, ABL Bilinear has been working perfectly for me in 2.0.5 with the Ender stock board. I've done numerous tests and can't get it to fail. Could this issue be related to #16617 where stealthchop is affecting baby stepping? Or something else specific to the silent drivers.

interstellarmisfit on 28 May 2020

I tried disabling stealthchop and my z axis motor made the most horrible gut wrenching noises.. lol maybe ill give that a shot again.. also I've been having this problem on integrated 2208's, integrated 2209's, non-integrated 2208's and non-integrated 2209's.

txt4nk on 28 May 2020

The problem does not affect 1.1.9 and drivers other than 2208 and 2209. I had no problem with my Creality Silent board running 1.1.9 and ABL. A friend has no problem with 2130 drivers on 2.0.x. (SKR 1.3). Never heard of problems from people running UBL, hence only ABL_BILINEAR is affected.

This appeared when switching to 2.0.x/.3/.5 with non-integrated 2208 drivers on an E3 DIP. One would think that this is a very typical hardware combo.

Alphaelectric on 28 May 2020

@Alphaelectric my request is based on SKR 1.3 and the TMC2130 driver. This problem also arises in conjunction with Mega ramps and TMC2130.
I do not think the problem is in the drivers.

komandrik on 28 May 2020

@Alphaelectric my request is based on SKR 1.3 and the TMC2130 driver. This problem also arises in conjunction with Mega ramps and TMC2130.
I do not think the problem is in the drivers.

Thanks for the statement. That makes it sound like my friend is indeed using UBL for his setup.

Alphaelectric on 28 May 2020

i still have a set of a4988 drivers, temted to stick those in there and see if that fixes it, could be something to where tmc drivers and marlin 2.0 just dont play nice with each other. i know that the tmc2208's and marlin 1.1.9 work fine on the mks gen L (atmega 2560) running all the abl modes.

rmitchell80 on 28 May 2020

i still have a set of a4988 drivers, temted to stick those in there and see if that fixes it, could be something to where tmc drivers and marlin 2.0 just dont play nice with each other. i know that the tmc2208's and marlin 1.1.9 work fine on the mks gen L (atmega 2560) running all the abl modes.

If you could do that for Marlin 2 that would be splendid. This test was never done as I recall.

Alphaelectric on 28 May 2020

i will do that but it may take me a few days to reinstall it to the printer and trya a few prints due to my work schedule. i will upload the config files and discription of the printer

rmitchell80 on 28 May 2020

i still have a set of a4988 drivers, temted to stick those in there and see if that fixes it, could be something to where tmc drivers and marlin 2.0 just dont play nice with each other. i know that the tmc2208's and marlin 1.1.9 work fine on the mks gen L (atmega 2560) running all the abl modes.

I have several printers. At all there is Marlin 2.0, I checked different versions, the error is everywhere. External drivers, used only by EN, GND, STEP and DIR. Only everything works fine on RAMPS1.4 and MKS GEN 1.4. At RURAMPS 1.4 (32-bit) the auto level does not work normally + the error increases with the table size with the height of the model. It's not about the drivers.

StrannikZet on 28 May 2020

kinda makes me wonder if its not something bigtree does differently with their boards

rmitchell80 on 28 May 2020

kinda makes me wonder if its not something bigtree does differently with their boards

I had a BTT mini e3 that was working freaking awesome.. got the tmc connection error problem and sent my mini board back for a replacement. In the mean time I put a th3d ez board in and I started having this issue. Pulled the ez board out and threw in an E3 dip with 2208's, same problem. I am now back on an E3 mini (exact same board that worked perfectly before) and the problem is still just as bad as ever. The one and only change is the firmware.. i went with the latest and greatest bugfix and it was a mistake lol

txt4nk on 28 May 2020

I have the same issue on a ramps board with aa9... drivers. Which doesn't
make searching easier admittedly

Am 28. Mai 2020 23:44:25 schrieb txt4nk notifications@github.com:
>

kinda makes me wonder if its not something bigtree does differently with
their boards
I had a BTT mini e3 that was working freaking awesome.. got the tmc
connection error problem and sent my mini board back for a replacement. In
the mean time I put a th3d ez board in and I started having this issue.
Pulled the ez board out and threw in an E3 dip with 2208's, same problem. I
am now back on an E3 mini (exact same board that worked perfectly before)
and the problem is still just as bad as ever. The one and only change is
the firmware.. i went with the latest and greatest bugfix and it was a
mistake lol
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Louis-Cypher on 29 May 2020

ok, so if everyone is having this problem on a multitude of drivers and board combos, could it be the probe, im using a bltouch. i dont know im just throwing out questions that i personally have not seen the answers to.

rmitchell80 on 29 May 2020

I have simple 5V inductive proximity sensor wired on Z switch pins.

salacpavel on 29 May 2020

I'm using the EZABL. Too many reports of different boards, drivers, and probes to really narrow this down to hardware, plus one user here has reported their hardware works fine using Klipper.

Ixian on 29 May 2020

i wish that there was a previous copy that was known to work and still run on 32bit

rmitchell80 on 29 May 2020

I'm using the EZABL pro mini, SKR mini E3 1.0 board with TMC2209 drivers. However, I was able to resolve my issue so it may have differed from everyone else's and the original reported problem.

The-slunk on 29 May 2020

I'm using the EZABL pro mini, SKR mini E3 1.0 board with TMC2209 drivers. However, I was able to resolve my issue so it may have differed from everyone else's and the original reported problem.

You care to share how you resolved it or you going to just leave that hanging out there or what? :) Maybe relevant, maybe not, wouldn't hurt to know.

Ixian on 29 May 2020

I'm using the EZABL pro mini, SKR mini E3 1.0 board with TMC2209 drivers. However, I was able to resolve my issue so it may have differed from everyone else's and the original reported problem.

You care to share how you resolved it or you going to just leave that hanging out there or what? :) Maybe relevant, maybe not, wouldn't hurt to know.

Haha sorry, I didn't realize how much the thread had grown since I posted my testing and solution. I commented out the extrapolate beyond bed option (unrelated I believe), commented out restore ABL after G28, and disabled the option to correct leveling after xxxmm (I believe M420). I'll edit my comment with the exact firmware options in a few since I'm working currently and can't open up my config file.

EDIT: current ABL related settings -

define AUTO_BED_LEVELING_BILINEAR (ONLY bilinear, before I had mesh and bilinear enabled)

//#define RESTORE_LEVELING_AFTER_G28
//#define ENABLE_LEVELING_FADE_HEIGHT

define SEGMENT_LEVELED_MOVES

define EXTRAPOLATE_BEYOND_GRID

//#define ABL_BILINEAR_SUBDIVISION

The-slunk on 29 May 2020

Went UBL this morning and did about 20 minutes of manual mesh leveling in the spots I was having issues and I have a near perfect 200x200 first layer. With this, I can go back into my mesh and manually change the few problem area's on the 200x200 print to achieve the perfect first layer. Thanks for nothing, bilinear lol

txt4nk on 29 May 2020

I'm using the EZABL pro mini, SKR mini E3 1.0 board with TMC2209 drivers. However, I was able to resolve my issue so it may have differed from everyone else's and the original reported problem.

You care to share how you resolved it or you going to just leave that hanging out there or what? :) Maybe relevant, maybe not, wouldn't hurt to know.

Haha sorry, I didn't realize how much the thread had grown since I posted my testing and solution. I commented out the extrapolate beyond bed option (unrelated I believe), commented out restore ABL after G28, and disabled the option to correct leveling after xxxmm (I believe M420). I'll edit my comment with the exact firmware options in a few since I'm working currently and can't open up my config file.

You get a chance to get your config?

Ixian on 1 Jun 2020

I'm using the EZABL pro mini, SKR mini E3 1.0 board with TMC2209 drivers. However, I was able to resolve my issue so it may have differed from everyone else's and the original reported problem.

You care to share how you resolved it or you going to just leave that hanging out there or what? :) Maybe relevant, maybe not, wouldn't hurt to know.

Haha sorry, I didn't realize how much the thread had grown since I posted my testing and solution. I commented out the extrapolate beyond bed option (unrelated I believe), commented out restore ABL after G28, and disabled the option to correct leveling after xxxmm (I believe M420). I'll edit my comment with the exact firmware options in a few since I'm working currently and can't open up my config file.

You get a chance to get your config?

Yeah sorry about that wait. Here it is:
Configuration.zip

The-slunk on 3 Jun 2020

Installed MarlinKimbra on a 32-bit board. There is no such mistake. There are flaws, but bearable. There is one more detail that you do not notice. The error depends on the size of the model according to XY. And added with the height of the model. Check the models, they may be higher than necessary.

StrannikZet on 5 Jun 2020

I fail to see how the height or X Y size of the model has anything to do with the fact that the z height is not correct...

txt4nk on 5 Jun 2020

Or anything in their post, including what MarlinKimbra has to do with this.

Wish folks wouldn't cross-pollute bug reports like this.

Ixian on 5 Jun 2020

I fail to see how the height or X Y size of the model has anything to do with the fact that the z height is not correct...

On large sizes, it may not be visible.
I printed a column 50 mm in diameter and 500 mm high - the Z dimensions are correct. Also, the size is correct if you simply raise the hotend in Z, without moving in XY. But if I print a model with a size of, for example, 300x300 mm in XY, then with each layer there will be an increase in height. The error is only if the board is 32-bit. I suspect that your first layer at each print, this is the increase in Z. I have it more globally. And depending on the location of the nozzle in XY, the sign of babystep in Z also changes, but this is probably not connected.

StrannikZet on 5 Jun 2020

I am having this issue are having the problem regardless of size. It can be a 5mm square or a 200mm square, the z height is not correct resulting in poor\failed first layers.

txt4nk on 5 Jun 2020

Could this be caused by a deviation between the first home command and slack/skipped Z steps by subsequent home commands (mixture of software and mechanical problem)?

Just a theory, but to explain the logic behind the theory:
You send a home command, and the probe measures point of contact as Z=0mm.
You raise the Z axis by lets say 10mm, but in actuality it travels only 9.80mm due to slack/skipped steps.
You home again, which should now drop the Z axis 10mm, but it only has to travel 9.80mm which in theory can either call for the original homing position (since it should be saved as 0mm - 10mm (distance traveled) resulting of a home position of -.20 )
or
(travel the correct distance to home (9.80) and average the new home position with the previous one (10-9.80)/2 = 0.10)

I know I'm reaching here, but this has been going on for a while and I'm just trying to brainstorm possibilities. When I was having this issue there seemed to be a difference in how frequently the issue occurred when the printer was just turned on and if it had been running multiple prints during that day. I figured this may relate it to M500 commands/restarts between homing/probing.

I guess this could be tested by running a M500 or restarting the printer between each step described by OP.

The-slunk on 5 Jun 2020

My Ender 3 is usually working in a fire and forget setup, meaning that in 9 out of 10 cases, the first layer is spot on after regular homing with mechanical end stops. As long as I was using a BLTouch to home Z, the printer determined "Z0". However, I was only getting a single good first layer in 1 out of 10 cases. I attribute this to pure chance, since in the other 9 cases, Z-offset was fluctuating from too close (ram nozzle into bed) to too far away (air printing).
Since my prints are usually of good quality, I can rule out serious mechanical issues such as skipped steps. The X-gantry is set to slowly descent under its own weight if the stepper motor is disconnected. Z-rod rests on a ball bearing coupler and the Z-nut is floating freely. Since I uninstalled the probe and went back to manual leveling, my first layers returned to normal.

Alphaelectric on 5 Jun 2020

👍1

My Ender 3 is usually working in a fire and forget setup, meaning that in 9 out of 10 cases, the first layer is spot on after regular homing with mechanical end stops. As long as I was using a BLTouch to home Z, the printer determined "Z0". However, I was only getting a single good first layer in 1 out of 10 cases. I attribute this to pure chance, since in the other 9 cases, Z-offset was fluctuating from too close (ram nozzle into bed) to too far away (air printing).
Since my prints are usually of good quality, I can rule out serious mechanical issues such as skipped steps. The X-gantry is set to slowly descent under its own weight if the stepper motor is disconnected. Z-rod rests on a ball bearing coupler and the Z-nut is floating freely. Since I uninstalled the probe and went back to manual leveling, my first layers returned to normal.

Thanks for confirming that my theory wasn't the case. Was trying to think outside of the box since the issue still isn't resolved for some, and it's been going on for so long.

The-slunk on 5 Jun 2020

Installed an EZABL on my ender 3 w/ SKR Mni E3 1.2 and I am being effected by the same issue.

Set z probe offset, check with feeler gauge, everything looks great. Go to print and I'm far off from the Z offset value previously set. Adjusted from -0.345 to -0.520 during the first layer for proper adhesion. Incredibly annoying.

Going to try UBL and pray.

viperguy212 on 11 Jun 2020

Confirming bug and workaround (it's come up before, but this bug report goes back 8 months so worth repeating):

The bug, and the steps to reproduce it, are in the very first post by komandrik. That issue has been marked confirmed and as of yet is not resolved. The steps to reproduce it are in that post; if you don't have that issue you either possibly have a different bug (check please, it helps the developers a great deal to keep reports organized) or you are just having regular leveling problems, there appear to be a lot of both kinds of reports here. Not a lot has changed since the initial report, which is pretty straightforward.

If you have this problem - and if you have that hardware combination and are using Abl_bilinear with a somewhat recent 2.0.x version of Marlin, you do - the workaround for now is to switch to another method. UBL is probably what most users with probes will want to go to, although you don't technically need a probe to use UBL (it is much easier with one). Note that UBL is pretty advanced and you should be prepared to do some research in to the needed config and setup changes to get it to work if you haven't done it before. With that said, I have found it provides a better leveling experience, overall, once dialed in.

I have run several days of prints now on my heavily modded Ender 3 Pro w/SKR Mini E3 2.0 (TMC2209 UART), Marlin bugfix 2.0.x, and an EZABL Pro probe. Once I got everything set up, dialed in, leveled, and got my Z offset right, I've been able to do dozens of prints, including several first layer test prints that cover most of the bed surface, without having to constantly power cycle or do anything other than normal printer stuff like touch up the Z if I change filament types and clean the PEI bed surface. My mesh has held and my Z offset is being used.

With that said I've been down this road before so who knows, maybe I am just lucky and I'm one spring compression away from it all going to hell again :) but if you are at your wits end with this bug and can't wait it out, try switching to UBL. It is worth the effort.

Ixian on 17 Jun 2020

I have gone UBL, and have the same issue. The only way to get good prints on UBL is to modify the mesh severely. My problem printer is a heavily modified ender 5 pro on a SKR E3 Mini (also tried two SKR E3 DIP boards and the th3d ez board lite, all show this exact problem). Putting those same DIP boards and ez board in my heavily modified ender 3, I am able to run bilinear, linear, ubl.. you name it, with absolutely perfect first layers.

txt4nk on 17 Jun 2020

Same here, went UBL and issue is still apparent. The only way I can get a decent layer is to fine-tune during the skirt. Although my initial G26 test print after setting up UBL and Z offset is perfect. After that, it all goes to hell.

viperguy212 on 17 Jun 2020

I have gone UBL, and have the same issue. The only way to get good prints on UBL is to modify the mesh severely. My problem printer is a heavily modified ender 5 pro on a SKR E3 Mini (also tried two SKR E3 DIP boards and the th3d ez board lite, all show this exact problem). Putting those same DIP boards and ez board in my heavily modified ender 3, I am able to run bilinear, linear, ubl.. you name it, with absolutely perfect first layers.

That doesn't make any sense, also can't tell if it matches the description of the bug in this report. Again, that's the Z height changing after G29 is issued again after a power cycle/initial G28 - check the steps and the posted logs.

What's happening is, printer boots, G28/29 issues, first print/layer goes fine (assuming something else isn't off), next print starts, G28/G29 issued again, and the Z height changes, which throws the first layer off. This will continue until the board (printer) is power cycled. Every time.

The issue points to something in the way the default mesh for ABL_Bilinear is being stored. In the case of UBL, where you specify a storage slot (S1, S2, etc.) this problem does not manifest, or at least I haven't reproduced the specific problem I just outlined with UBL. Not to say there may not be other issues with UBL (bugs, user error, config issues, whatever) but I can reproduce the error in the original post every time, easily, with ABL_Bilinear, and so can many others who posted. That's why the bug got confirmed.

Since then we've gone down a rabbit hole of other issues. I'm not saying you aren't having problems or that they aren't worth taking seriously, but the way they are being reported, here in a long running, specific bug report, in the vague manner they are is unlikely to get them resolved.

Have you posted your logs? I don't know that anyone could troubleshoot based on your description.

Ixian on 17 Jun 2020

I have posted much more information in other bug threads, even tried a tweaked firmware from thinkyhead. We are still waiting for someone with more coding knowledge to look at the information that myself and a few others reported. But ill leave my comments and such in those threads 👍

txt4nk on 17 Jun 2020

@komandrik
Please test the bugfix-2.0.x branch to see where it stands.

boelle on 23 Jun 2020

Has anyone found ABL worked properly on any version of Marlin 2.x and if so which version was it?

iammenotyou on 13 Jul 2020

i know that i havent. teaching tech just came out with a video showing how to get rep reap working on the skr boards and im thinking about doing that just to expirement

rmitchell80 on 13 Jul 2020

I wanted to try that a while back, but It only works on LPC1768\1769 based boards, so it will only work on the SKR 1.3 and 1.4. Pondering if I should buy yet ANOTHER in the effort of getting this bug out of my life.

txt4nk on 13 Jul 2020

the other alternative is to install klipper which i have not tried, i think that it is bull that they have left us hanging for this long

rmitchell80 on 13 Jul 2020

I know! The unpaid volunteers who work on the free software for our printers have been slacking way too long, the cretins. We should all leave en-masse for another free software project like Klipper. Surely it doesn't have bugs, and if does, we can just bug their unpaid force to fix them for us too, maybe they'll be more responsive.

Or, maybe instead not vent in comments and otherwise clutter up bug reports? Because this isn't helping.

Ixian on 13 Jul 2020

👍2

i understand that they are volunteers that are working on the project and i understand that they are not going to be able to work on this 24/7. all that i am sayiung is that this bug has gone for a good while and needs to be fixed or atleast aknowledged, i havent seen anyupdates addressing this issue or atlease someone saying we are still working on this issue. i would just like to a update to the situation instead of being left in the dark. ok now i will get off my soap box and return you to your previously scheduled program...

rmitchell80 on 13 Jul 2020

👍1

@rmitchell80 leveling issues are complicated, because they are often unique to a users exact hardware/configuration/workflow. Combine that with the finite amount of time people have to actually spend investigating issues. My current PR related to BLTouch probing issues took me 10-15 hours of debugging (basically my entire weekend) to result in only a few changed lines of code.

Many of us are using ABL just fine on these boards, but I for instance rarely would run G29 twice without power-cycling. I save my mesh to EEPROM and only re-probe when absolutely necessary. I suspect most people actively fixing things don't pay a lot of attention to something like ABL failures, if ABL seems to be working fine for them.

sjasonsmith on 13 Jul 2020

@rmitchell80 if you try the reprap firmware please share your findings. Also thinking of purchasing a SKR 1.4 - just noticed T.T. didn't provide much detail on ABL configuration.

@sjasonsmith Appreciate that, but for some of us, even without running G29 twice, bed leveling is not working correctly. So its disappointing to see so little attention received for an issue that for some of us is important.

iammenotyou on 13 Jul 2020

I've since switched to UBL, which in addition to being a little more accurate overall allows me to save meshes to specific slots, making for easier bed swaps between my PEI and glass surfaces, and don't have this problem any longer. Based on the original description, the one that's been replicated, it's some kind of memory bug most likely, especially given that explicit mesh saving seems to mitigate or avoid it.

Though at this point there are so many mixed reports, with very little troubleshooting info (and a few well-informed reports with logs) it's hard to say. I don't envy any dev trying to run this down, I don't even think there is consensus on what "this" is. There are a lot of scattered reports, for example, that are clearly from inexperienced users confusing run of the mill Z-offset issues with a "bug". And a few that do indicate a more serious problem, but where to start to look to fix it? There's no clarity on this issue.

If any user is willing to actually consider, for example, switching to Klipper just to try to "fix" this - a pretty involved step, by the way - that same user should at least give UBL a try, a proper, give it a chance, do the research, don't get frustrated, get it working properly try. It works and a heck of a lot easier than swapping out the entire lot for Klipper, fine PrinterOS that it is.

Ixian on 13 Jul 2020

I do want to clarify this, I do appreciate the effort that has been put forth into the marlin firmware, and I am not ripping on that. I also understand that there are alot of different configurations out there cause nobody is running the exact same cong as the next person. When I mentioned klipper or rep rap, I was just giving alternatives that I have considered untill this issue can be resolved. I also want to express that I am not trying to pick a fight, but forgive me if I vent a little as I am human like the rest of us. If I was able to contribute to the fixing of this issue I would, but trust me your dont want me messing with the code as it would be unusable by the time I'm done.

rmitchell80 on 13 Jul 2020

@Ixian UBL is not a solution! If the table descends in Z under its own weight or the motors do not work evenly, you cannot use this mode, since the height will arbitrarily change with each print. UBL is well suited for Voron, where the table stands in one place!

Now, in discussing the problem, we delved deeper and moved away from the biggest firmware error. I sometimes help friends configure firmware on different motherboards, and everyone has this error.
The error is that after the G28 command we get a certain height of the Z axis. Which consists of the nozzle lift height and offset_z. After executing command G29, the final height of the Z axis changes. For some, the height of the Z axis changes upwards - they get normal prints, since the height of the first layer becomes smaller and the print is smeared into the table. For whom, after G29, the height changes in a smaller direction, they get a bad first layer, since instead of 0.2 they get 0.3 and sometimes 0.4 mm, despite the fact that the nozzle is also 0.4 mm.

@rmitchell80 I switched to Klipper a long time ago and now I have no problems with changes in the height of the first layer. I can start different prints many times without turning off the printer and without restarting the printer. But the problem that I raised in this request I constantly meet with Marlin users.

komandrik on 14 Jul 2020

@komandrik, thank you for letting us know that Klipper is working. i just hate to dedicate my pi to be the "cpu" of my printer, that is the reason that i havent tried it.

rmitchell80 on 14 Jul 2020

Just wanted to report that with an SKR V2.0 this issue is still persistent with. I'm seeing a +0.2 difference just between layers 1 and 5. May just turn ABL off completely at this point (unfortunately).

viperguy212 on 15 Jul 2020

Do I understand correctly, that until this bug is fixed, power cycling the printer between every print corrects the Z raise?

blueeagle69 on 20 Jul 2020

I didn't help me.

Alphaelectric on 21 Jul 2020

I didn't help me.

Thanks for the response 😣
I've recently gone back to 2.01 for the time being.
That seems to behave as far as I can see. (Although I could be mistaken).

blueeagle69 on 21 Jul 2020

It is very difficult to follow which issues people are actual discussing here, because it has gone on so long with so many comments.

Recently some issues with BLTouch probe consistency were fixed for all STM32 boards.
If you use a BLTouch and were having issues on STM32 you should re-test the bugfix-2.0.x branch to see if your issue is resolved.

Another change related to ADAPTIVE_STEP_SMOOTHING impacts any board. Excessive CPU usage may have interfered with the probing process. If you have that feature enabled you should retest the bugfix-2.0.x branch.

For anyone still having problems, the following would be helpful. It may repeat what was said earlier, but it is too difficult for any dev to look at all the comments above and sift out useful information.

Confirm whether the issue matches the original issue in this report. If not, your reply probably belongs in a different issue, to let this focus on one problem.
List board and probe type
Provide probe accuracy results from M48 P50
Include full summary, not only standard deviation. Range is the most important detail I am looking for.
Attach zip file with new config files for bugfix-2.0.x that you used to reproduce the issue.

sjasonsmith on 21 Jul 2020

👍1

UPDATE: I was using the Bed Visualizer in Octoprint to run the tests. After disabling ADAPTIVE_STEPPING,enabling BLTOUCH_FORCE_SW_MODE, and removing the additional gcode from the Bed Visualizer plugin (for disable temp reporting) this problem only happens occasionally and ONLY when G29 is run from the Bed Visualizer.

I am having this same issue. I have tried both Marlin 2.0.6 and the bugfix-2.0.x branch. I have tried with adaptive smoothing both enabled and disabled. When disabled, it actually makes the problem more frequent. After some number of G29 commands(in one test, it was the first G29 after power cycle), it will start to report that the bed is raising by some arbitrary value(.2mm in the test below).

I am using an SKR Mini E3 v2 and a genuine Bltouch 3.1

M48 P50 results (before first G29)
Recv: Finished!
Recv: Mean: 0.159850 Min: 0.158 Max: 0.165 Range: 0.007
Recv: Standard Deviation: 0.001534

My first G29 (they stayed consistent for several runs on this test)
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 +0.215 +0.138 +0.290
Recv: 1 +0.195 +0.170 +0.270
Recv: 2 +0.345 +0.172 +0.237

I ran several G29's and thought I was good to start adjusting. After one adjustment, I did a couple of G29 runs, and the problem started to manifest itself (let's call that G29 run X).

G29 run X:
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 +0.590 +0.493 +0.655
Recv: 1 +0.570 +0.538 +0.652
Recv: 2 +0.692 +0.550 +0.665

G29 run X+1
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 +0.770 +0.675 +0.832
Recv: 1 +0.757 +0.715 +0.832
Recv: 2 +0.875 +0.730 +0.842

G29 run X+2:
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 +0.950 +0.855 +1.010
Recv: 1 +0.937 +0.893 +1.013
Recv: 2 +1.050 +0.908 +1.025

M48 P50 results after the errant G29's:
Recv: Finished!
Recv: Mean: 1.203149 Min: 1.200 Max: 1.207 Range: 0.007
Recv: Standard Deviation: 0.001644

Configs attached. Thank you for any help you can provide.
Marlin_config.zip

greghavens on 2 Aug 2020

I am having the same issues, and my auto bed leveling is so unusable that I'm having to bypass it and manually level my bed. I'm not sure what portion of that is related to this particular bug. Essentially the ABL always seems to place the nozzle too high on the left, and too low on the right (variation is a bit more complex). This continues to happen on a manually leveled bed. What's interesting is that this behavior even continues if I go so far as to place a metal ruler under the bed on the left-side to dramatically reverse the tilt.

Setup:
Creality Ender 3 Pro, SKR Mini E3 v2, Genuine Bltouch 3.1
I'm using the current Marlin bugfix-2.0.x as of this post

Send: G28
Recv: X:172.00 Y:129.00 Z:7.50 E:0.00 Count X:13760 Y:10320 Z:3000
Recv: ok
Send: M113 S2
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 -0.185 -0.078 -0.080
Recv: 1 -0.048 +0.005 -0.033
Recv: 2 +0.182 +0.200 +0.077
Recv:
Recv: X:235.00 Y:228.00 Z:7.51 E:0.00 Count X:18800 Y:18240 Z:3000
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 -0.170 -0.062 -0.075
Recv: 1 -0.050 +0.013 -0.025
Recv: 2 +0.190 +0.197 +0.085
Recv:
Recv: X:235.00 Y:228.00 Z:7.51 E:0.00 Count X:18800 Y:18240 Z:3000
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 -0.158 -0.040 -0.053
Recv: 1 -0.028 +0.035 -0.003
Recv: 2 +0.212 +0.220 +0.107
Recv:
Recv: X:235.00 Y:228.00 Z:7.50 E:0.00 Count X:18800 Y:18240 Z:3000
Recv: ok

Send: G29
Recv: Bilinear Leveling Grid:
Recv: 0 1 2
Recv: 0 -0.108 +0.000 -0.013
Recv: 1 +0.013 +0.075 +0.037
Recv: 2 +0.253 +0.270 +0.148
Recv:
Recv: X:235.00 Y:228.00 Z:7.45 E:0.00 Count X:18800 Y:18240 Z:3000
Recv: ok

Because my bed is already pretty level, I posted 4 passes. It seems that the more level the bed, the slower the creep. You can also see that the rate of creep increases with each pass.

Marlin bugfix-2.0.x
marlin config.zip

I just spent the money and time to buy and install an SKR E3 Mini v2.0, Hero me gen5 setup with dual 5015 fans, and the latest BLTouch device. I spent days trying to get the ABL to work and trying to figure out what I was doing wrong. It's frustrating not having this feature. Any help to get it back up and running would be appreciated.

coreyo on 6 Aug 2020

Complaining about what you spent isn't relevant, also ironic, given that the one thing you didn't spend anything on was Marlin, the free project with a number of volunteer developers that has a bug you are upset about. Please stick to data that's helpful in troubleshooting the issue.

Ixian on 6 Aug 2020

For those people here that have enough free flash available: Unified Bed Leveling is a perfect replacement for the broken bilinear implementation. I have set it up twice now on my CoreXY and lately also on the Ender 3. Both working flawlessly on SKR 1.3 with Marlin 2.0.5 and TMC2209. I have given up on bilinear and am not looking back. So there is at least some good that came of it: technologically my printers evolved.

Alphaelectric on 6 Aug 2020

I wanted to leave an update here as well. It turns out my problems with Z Offset are not solved by avoiding the Bed Visualizer in Octoprint. The issue still happens, just less often. Going to try UBL as suggested above.

greghavens on 6 Aug 2020

Does re-homing with G28 between G29 runs hide the issue, or are you already doing that?

sjasonsmith on 6 Aug 2020

I haven't run G28 _every_ time but I have run it when trying to debug this BEFORE disabling Adaptive Stepping. When I did try it, it did not correct the issue. I was running it to see if there were Z axis changes in the Safe Auto Homing when the offset started changing (there wasn't).

greghavens on 6 Aug 2020

The only repeatable action I have seen is a power cycle; after each one other users have reported the first print/ABL works as expected, then the problem starts to return until the next cycle. I was able to duplicate this myself last time I tested.

My suspicions still lay in the area of the extended memory on some of the RTC 6 chips used - I know most of the BTT boards like the SKR Mini, etc. and Reddit guides for same advise building with the STM32F103RC_bigtree_512K environment (even though there's still confusion over whether some boards actually have 512k vs. 256k). As the issue is solved with a power reset that clears volatile memory I'm wondering if that is where the problem is.

I don't have access to one of those boards in a test environment at the moment but what might make for an interesting experiment is if someone could do a build using the STM32F103RC_bigtree environment (that's the default 256k one, change platformio.ini) leaving everything else the same. It should still work fine unless you have really loaded up your config with memory-hogging options. See if the problem continues.

Ixian on 6 Aug 2020

I have tested power cycling as a fix and it didn't always help. The test run prior to the one I documented above showed the issue on the first G29 after power cycle.

I don't have access to one of those boards in a test environment at the moment but what might make for an interesting experiment is if someone could do a build using the STM32F103RC_bigtree environment (that's the default 256k one, change platformio.ini) leaving everything else the same. It should still work fine unless you have really loaded up your config with memory-hogging options. See if the problem continues.

I'll try this. Also willing to ship you a v2 board if that helps.

greghavens on 6 Aug 2020

Or maybe I'm not going to try it.

[redacted]/.platformio/packages/[email protected]/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\STM32F103RC_btt\firmware.elf section .rodata' will not fit in regionrom'
[redacted]/.platformio/packages/[email protected]/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: region `rom' overflowed by 17812 bytes
collect2.exe: error: ld returned 1 exit status
* [.pio\build\STM32F103RC_btt\firmware.elf] Error 1

greghavens on 6 Aug 2020

Willing to bet you could carve less than 18kb out of your config somewhere. Custom bootscreens, if you use them, are 1.4Kb. Disabling ARC_Support (used by CNC/laser) is 3.3Kb. Ditching the useless LCD_INFO_MENU is 1.7Kb. Enabling SLIM_LCD_MENUS which get rid of a lot of the extraneous crap in advanced config like velocity, etc. (which imho are better done through gcode/config anyway, not your LCD) is 5.4Kb. And so on. Chances are you would benefit from doing some flash memory optimization anyway but worst case just try it for a test build for this issue.

Ixian on 6 Aug 2020

I'm afraid it doesn't have anything to do with extended memory. I have been running BLTouch in a stock firmware environment and had nothing but issues.

Alphaelectric on 6 Aug 2020

Does re-homing with G28 between G29 runs hide the issue, or are you already doing that?

Homing again with G28 before every G29 does indeed prevent the creep that you get from consecutive G29 runs.

However, I don't think that this helps us. The observed problem is that the Z coordinates are no longer relative to the original origin after a G29 bed level. I suspect that the problem is much worse, in that the Z axis is offsetting after every single probe point in the mesh. This might explain why the nozzle is always closer to the same side of the bed, and too far away from the other side of the bed, even when I level the bed to slant dramatically in the opposite direction. Is anyone else experiencing this?

Likewise, I've tried doing the following in my slicer Start G-code settings:

G28 ; Home all axes
G29 ; Auto Bed Level
M500 ; Save Settings (including ABL mesh)
G28 ; Home axes again (remove erroneous ABL offset)
M420 S0 ; Restore ABL mesh settings

But the aforementioned problem is still there. If I've made a mistake in my fix method, let me know.

coreyo on 6 Aug 2020

Complaining about what you spent isn't relevant, also ironic, given that the one thing you didn't spend anything on was Marlin, the free project with a number of volunteer developers that has a bug you are upset about. Please stick to data that's helpful in troubleshooting the issue.

I can understand your impulse to become defensive, but I urge you to re-read my post. I simply said that I was frustrated and looking for help. I didn't insult anyone, and I didn't blame Marlin or the devs for anything. I'm happy to help to solve the issue if we can get the ABL feature working again.

If I set default_envs = STM32F103RC_btt in my platformio.ini file, I receive the same error about rom overflow as @greghavens. This is based off of the default configs for the SKR E3 mini v2.0 provided in the sample configs repository. I've only recently started looking at the codebase and feature sets. If you'd like to suggest some edits to my configs that would reduce the ROM size, I'd be happy to try it and see if the issue persists. I'm not knowledgeable enough to know if the configs for the other versions of the SKR boards would even work with the v2.0 hardware.

I should also point out that one of the other posters is having the same problem on the v1.3 board. Does that also use the *btt_512K version? I know that there was an issue with part of the ROM not being useable on some of the earlier SKR mini boards, but that was supposed to have been fixed in v2.0.

coreyo on 6 Aug 2020

The SKR 1.3 uses the LPC1768 and is different in other ways as well. I wasn't suggesting this was specific to the BTT boards, or even the extra flash memory space, just suggesting different troubleshooting steps to try.

My post a few above this one has some things you can look for to optimize flash memory usage in Marlin. It's a good idea to do so anyway. If you are using the board with an Ender printer - if you have an SKR E3 model then I assume that would be the case but you never know - you can follow this excellent guide on Reddit for setup, good tips, also has some optimizations in there. https://www.reddit.com/r/ender3/comments/h8y1ia/marlin_20x_guide_skr_mini_e3_v20_ender_3/

And like I and others have been saying, while it may not be appropriate for everyone, UBL does work and will probably work just fine, if not even better, for many of the people struggling here. The guide I just linked has good tips on getting it working too. There's more of a learning curve to UBL but it is worth it, in my opinion.

Ixian on 6 Aug 2020

Or maybe I'm not going to try it.

[redacted]/.platformio/packages/[email protected]/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\STM32F103RC_btt\firmware.elf section .rodata' will not fit in regionrom'
[redacted]/.platformio/packages/[email protected]/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: region `rom' overflowed by 17812 bytes
collect2.exe: error: ld returned 1 exit status
* [.pio\build\STM32F103RC_btt\firmware.elf] Error 1

Using build flag "-fno-threadsafe-statics" should save you like 40k bytes.

The-slunk on 7 Aug 2020

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

github-actions[bot] on 6 Sep 2020

@boelle Is there some way to keep the bot from closing this issue? Just because it cannot be fixed doesn't mean it doesn't exist.

Alphaelectric on 6 Sep 2020

Simply replying should cause it to stay open. The label should be removed the next time the bot runs.

Let’s use this as an experiment to see if that works correctly. If it doesn’t work correctly tag me and I’ll come fix it.

sjasonsmith on 6 Sep 2020

I seem to be having the same issue with UBL. All of my prints seem to have the same issue as when I use ABL: The nozzle is too high on the left-hand side of the build plate, and too low to the right-side of the build plate. The original test mesh print from the firmware seemed okay after the initial mesh, but after loading the mesh and probing 3 points to adjust for tilt, the print will fail. I tried skipping the 3-point probe and saw the same results.

coreyo on 16 Sep 2020

Accidentally came across this post looking for something else...
For what its worth, I just got a new Ender 3 Pro and only upgraded done was board to SKR mini e3 v2. No ABL and only mesh_level in marlin active.
I was using CHEPS stl for corner leveling and I noticed the Z lower a hair after the 1st round of 4 corners (it stops after 2 times)... this happened repeatedly and thought that maybe it was in the STL. However, when I used this STL on the same printer prior to marlin/board upgrade I did not have the issue.
Not sure if its related but thought I'd drop this line.

docmalc on 28 Sep 2020

Same issue, printing is impossible on cr-10, skr 1.4 with ABL. Left side is too much squished, right side is extruded in thin air.
The error on bed mesh is +-0.2.
The bed is only compensated in the Y, not on the X.
Also, the leveling position is wrong altogether, #19409

Liger0 on 13 Oct 2020

Yeah, I wrote same here #19839
I Have ender 3 with V427 and marlin 2.x and BLtouch looks like it's all fine on bed visualisation, its not compensating. I've changed baord back to stock and marlin 1.1.9 and it's all good there printing fine on a slope.
So there is soemthing wrong in marlin 2

gbkwiatt on 25 Oct 2020

I have got the same issue on mks s gen l, current bugfix, set to bed leveling bilinear with bl touch, tmx 2130.

I have been observing and wondering about this for quiet some time. For example, at the first layer, lines get squashed flat on the front left and when the nozzle moves to the right, the filament gets thinner and round, up to the point of gaps between the lines.

My Z offset is ok, it stays the same between prints, between power cycles, levelling (which I do in the start gcode, so on every print) and firmware upgrades. I have the Z offset in the configuration file so it gets loaded to eeprom after firmware upgrades with M502 M500.

Substeps ist set to 32, ADAPTIVE_STEP_SMOOTHING is on, integrated baby stepping is on, BABYSTEP_ZPROBE_OFFSET is on, S_CURVE_ACCELERATION is on, hybrid and stealth chop is off because it produces very jerky movements even at low speeds and accelerations.

hamster65 on 25 Oct 2020

I was fighting with it for a week, I used to have ender 3 with marlin 1.1.x long time ago with BLtouch and never had to level the bed manually. Now I got ender 3 again but with V427 board I've installed BLtouch and had nothing but problems with leveling. People were saying that you have to perfectly level the bed manually for BLtouch to work.. And I was like what? What's the point of having BLtouch then... I did put back 1.1.4 baord to ender 3, and installed marlin 1.1.9 and "leveled" bed to a slope and it printed well with no problems.
So conclusion is, there is something wrong with marlin 2.
I am happy to help with diagnostics and trying to find the problem, as I really want to use 32bit silent baord.
If you need me to do anything I am happy to help

gbkwiatt on 25 Oct 2020

👍1

I have just did the test, and follow creality manual for v427 board and bltouch. Installed bltouch on pin27 with LCD breakboard instaed of dedicated bltouch connector, also installed they bersion of marlin 2.0.1 - (creality calls it 1.3.1) and bl touch works. I have made a 1 corner higher by like 3mm or more and it didn't crash nozzle into bed like It did before. However, when I ran print test with 4 corner prints, it's still not consistent, in the highest corner nozzle is to high and in lowest corner nozzle is too low, while middle of the bed seems perfect.

gbkwiatt on 25 Oct 2020

I upgraded to 2.0.7.1 non-bugfix, and just chiming in since i just noticed that behaviour too.
I didn't have enough time today to make more tests, but sure will in the following days.
I have a bad case of unlevel bed (2mm height difference from front to back, measured by my bltouch) since i just upgraded my machine.
So with that big of a height problem, it is pretty apparend when something isnt working correctly.
I'm measuring the bed correctly when using "G29 P1" (by looking at the output of the mesh), however the z-motor is not moving at all after using "G29 J" (ofc. after saving the mesh previously).

I will report soon with the bugfix branch.

EDIT: So after porting my Settings over to the bugfix branch, it works as expected.

berryelectronics on 26 Oct 2020

Marlin: [BUG] SKR 1.3 and ABL_BILINEAR - changes the height of the z axis.

Steps to Reproduce

Most helpful comment

All 221 comments

define AUTO_BED_LEVELING_BILINEAR (ONLY bilinear, before I had mesh and bilinear enabled)

define SEGMENT_LEVELED_MOVES

define EXTRAPOLATE_BEYOND_GRID

Related issues