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

[komandrik]

Config.zip

At the time of writing, the latest version of Marlin 2 - bagfix is installed.

After executing the G29 command, the actual height of the Z axis changes. This leads to a poor first layer. Below is the log received in the terminal from the octoprint:

Send: G28
 X:146.00 Y:34.00 **Z:11.30** E:0.00 Count A:28800 B:17920 Z:4520
 ok
Send: M113 S2
 ok

Send: **G29**
 Bilinear Leveling Grid:
       0      1      2      3
  0 +0.095 -0.017 -0.040 +0.028
  1 +0.095 +0.018 +0.020 +0.092
  2 +0.090 +0.038 +0.065 +0.153
  3 +0.060 +0.043 +0.095 +0.207
  X:270.00 Y:129.00 **Z:11.18** E:0.00 Count A:63840 B:22560 Z:4474
 ok

Send: **G29**
 Bilinear Leveling Grid:
       0      1      2      3
  0 -0.015 -0.127 -0.150 -0.092
  1 -0.015 -0.092 -0.090 -0.017
  2 -0.020 -0.072 -0.045 +0.043
  3 -0.040 -0.058 -0.005 +0.087
 X:270.00 Y:129.00 **Z:11.29** E:0.00 Count A:63840 B:22560 Z:4518
 ok

Send: **G29**
 Bilinear Leveling Grid:
       0      1      2      3
  0 -0.023 -0.125 -0.147 -0.090
  1 -0.012 -0.100 -0.097 -0.015
  2 -0.017 -0.070 -0.043 +0.025
  3 -0.048 -0.065 -0.002 +0.090

 X:270.00 Y:129.00 **Z:11.30** E:0.00 Count A:63840 B:22560 Z:4520
ok

Offset_Z in firmware -1.3 As you can see, after the first G29 command, the Z-axis height becomes 11.18. Offset_Z is changed to 0.18. If I send the G29 command again, the offset changes to 0.01 again, I send the G29 command and get the desired Z-axis height. I have a 0.4 mm nozzle. The height of the first layer is 0.2 mm. If I do not send the G29 command twice, the first layer will be 0.18 mm higher. It will be 0.38mm and the plastic will not stick to the table. The change in the height of the Z-axis, after the G29 command, is not always the same. Sometimes the change is less than 0.1mm and then it does not affect the print.

Steps to Reproduce

1. send the G28 command and see the height of the Z-axis
2. send the G29 command and see the height of the Z-axis
3. repeat the G29 command and see the height of the Z-axis

Expected behavior: [I expect to get the height of the axis Z 10mm + Offset_Z 1.3mm = 11.3mm]

Actual behavior: [I get the height of the Z-axis every time. For normal printing, I need to send the G29 command twice]

Link to configuration files and text file of terminal session octoprint: https://drive.google.com/open?id=1aWkorl8BigrBCP1FCaHMhVViqYRYAMwk https://drive.google.com/file/d/1p39olfB29Xj4qYm8yFTWILc8dkShT6dr/view?usp=sharing https://drive.google.com/file/d/1rNqWhd-X-nW-1t3UrYz2H6kVHO_5O8fa/view?usp=sharing

Link to video https://photos.app.goo.gl/ydcEcpzeSo6AgR2RA

P.S. I'm sorry, but I'm writing a translator through Google.

[salacpavel]

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 .

[komandrik]

@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)

[salacpavel]

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.

[komandrik]

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

[Neverther]

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).

[tvixen]

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

[gloomyandy]

@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.

[komandrik]

@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.

[tvixen]

@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.

[salacpavel]

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]

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.

[tvixen]

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.

[reloxx13]

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

[tvixen]

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.

[reloxx13]

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...

[komandrik]

@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.

[tvixen]

@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.

[boelle]

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

[komandrik]

@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.

[salacpavel]

@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

[boelle]

@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

[InsanityAutomation]

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.

[komandrik]

@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.

[aleknest]

Have same problem.

[salacpavel]

@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.

[hapklaar]

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)

[Louis-Cypher]

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]

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]

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]

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.

[salacpavel]

Could some devs pretty please look at this issue and fix it?

[komandrik]

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

[Louis-Cypher]

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

[komandrik]

@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

[salacpavel]

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_ ```

[boelle]

@komandrik i assume this is still an issue?

[komandrik]

Yes, the problem still remains.

[hackebike]

my issue bug 15809 might be related ?

[pfillion42]

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

[Louis-Cypher]

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.

[komandrik]

@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.

[boelle]

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?

[pfillion42]

@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.

[Neverther]

@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.

[Louis-Cypher]

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.

[pfillion42]

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

[Louis-Cypher]

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.

[komandrik]

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

[pfillion42]

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

[Louis-Cypher]

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.