search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

[BUG] Z drift when enabling leveling after G28 #16660

Closed houseofbugs closed 4 years ago

houseofbugs commented 4 years ago

Bug Description

Z Height is incorrectly set and shown on the LCD display.

Steps to Reproduce

RESTORE_LEVELING_AFTER_G28 Steps:

  1. Enable RESTORE_LEVELING_AFTER_G28 in firmware
  2. Home the printer (G28)
  3. In my build Z height after homing is set to 5, Z shows 5 on LCD
  4. Send G29 to generate mesh
  5. Send G28
  6. Z Height now shows not 5 (ex; 4.98, 5.02) and is not at 5mm anymore

Enabling Bed Leveling from LCD Steps

  1. Home the printer (G28)
  2. In my build Z height after homing is set to 5, Z shows 5 on LCD
  3. Send G29 to generate mesh
  4. Send G28
  5. Enable Bed Leveling from LCD Menu
  6. Z Height now shows not 5 (ex; 4.98, 5.02) and is not at 5mm anymore
  7. If you then disable Bed Leveling from the LCD Menu Z will show 5 again

Expected behavior: Z height should be the actual height set to the Z height after homing.

Actual behavior: It appears to be skewing the Z height after mesh generation based on whatever deviation your probe has. If you have a less accurate probe the difference in the Z height will be more incorrect vs a probe that is very accurate. Restarting the printer after every print "fixes" the issue but only for that 1 print.

I suspect that however the mesh is being applied after generation with these features is not using the value from G28 (or G28 Z) which is skewing the Z height. If you disable the RESTORE_LEVELING_AFTER_G28 and only use G28, G29 when starting a print the issue does not present itself.

This bug is present in Marlin 1.1.9 and 2.0.bugfix as of posting this

boelle commented 4 years ago

this seems to be a dubilate of #15450

@houseofbugs is the issue the same?

1.1.9 are not longer worked on actively by the maintainers (me not one of them) 2.0.1 is a frozen copy of bugfix 2.0.x so always best to use 2.0.x

houseofbugs commented 4 years ago

Scott and I have been discussing this a lengths. It's still present on bugfix as of the time I made the post. Its not a huge discrepancy when you have a machine that is well dialed in physically and a probe that gets good accuracy.

The issue was alerted to me by a guy with a BL Touch that had poor accuracy so the skewed number was more noticeable.

I don't see it presenting itself too much on my machines but they are very well dialed in but it's definitely present on them. We're talking like 0.001mm of "drift" on them which is why it went unnoticed for a long time.

houseofbugs commented 4 years ago

Things Scott and I discussed offline:

InsanityAutomation commented 4 years ago

I believe the issue is somewhat related to the placement of set_bed_leveling_enabled(leveling_was_active); after all homing movement is complete. You're applying the leveling offset, and it sees where its supposed to be, but there is no command actually moving it to 5.0mm in this case.

Perhaps a flag is needed on set_bed_leveling_enabled to move to the expected readout position.

Another solution would be to move the Z post position command to after the apply leveling in the base routine instead of buried where it is now.

Keep in mind this is from a 20 minute glance and I havnt had time to sit down and test things in any in depth fashion.

thinkyhead commented 4 years ago

In our testing with two CR-10S machines we see correct behavior.

The original post mentions that the Z position changes when you enable and disable leveling. This is completely normal. You want Z to change based on the mesh beneath it when enabling or disabling leveling. As noted it goes back to 5 when leveling is turned off, so the reciprocal correction is working.

Here's the boilerplate procedure that we need someone who can reproduce the issue to run for us:

If the problem can be reproduced simply with G28 (as with RESTORE_LEVELING_AFTER_G28) then just do some G28 and G1 moves so we can see some G28 output. If the problem appears at this point, great! We have some useful info, so:

If you need to do other things to get the symptom to appear, please take notes and report the exact steps needed to get the Z error.

Thanks!

Vertabreak commented 4 years ago

I've been fiddling with this also since the live stream. I've so far been unable to produce the effect with ubl. It's something I'll be tinkering with and post if I come up with anything helpful.

thinkyhead commented 4 years ago

I'm gratified to confirm, anyway, that the correction applied when turning leveling on and off is consistent. It is, after all, just adding or subtracting the same interpolated Z offset of the bed at that XY position, and that is not a number that will change as you turn leveling on and off.

As far as re-enabling leveling within G28, the thing I would be most concerned with is that the current_position is fully up to date and the planner is synced with the current XYZ before re-enabling leveling.

It also came up that now that we have the extra space and speed on 32-bit, there is no reason not to enable ABL_BILINEAR_SUBDIVISION on those boards to get a somewhat better set of interpolated Z values.

houseofbugs commented 4 years ago

I'm going to get more scientific with the testing. I have to print a dial indicator mount to test and see actual z height after the probe offset is set. The validation of something with the Z height "drifting" was that after back to back prints or steps performed the nozzle usually ends up closer and closer to the bed with each repetition. Resetting the machine or rebooting it fixes this. I wish I had more pinpointing as to what is doing this and will work to getting more data and videos showing the issue.

houseofbugs commented 4 years ago

I strapped a Mitutoyo dial indicator on to a machine here with the latest 2.0.x bugfix flashed. Config is below that was used. I can 1000% for sure say this is NOT a hardware issue but a firmware bug.

I will test with the options you mentioned above and report back later today. I am dedicating many hours today to testing this bug.

Video of Testing: https://www.youtube.com/watch?v=fztDI3ns03M

Firmware Used: https://content.timothyhoogland.com/files/ShareXUpload/EZ300_1300CST_012520_2.0.xbugfix.zip

Machine Info: MKS Gen L EZABL V3 Kit TMC2208 on XY, A4988 on ZE Artillery AL-4 (modded) w/ Dual Z + Linked Rods + Dual Motors

houseofbugs commented 4 years ago

In our testing with two CR-10S machines we see correct behavior.

The original post mentions that the Z position changes when you enable and disable leveling. This is completely normal. You want Z to change based on the mesh beneath it when enabling or disabling leveling. As noted it goes back to 5 when leveling is turned off, so the reciprocal correction is working.

Except in the video I posted above you can clearly see after homing the nozzle is the same distance off the plate and its showing 5.16mm when its actually 5mm. I am not seeing it "compound" the Z distance. It appears to always be off the same amount. If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.

Here's the boilerplate procedure that we need someone who can reproduce the issue to run for us:

  • Download Marlin bugfix-2.0.x to test with the latest code.
  • Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
  • Connect to your printer from host software such as Cura, Printrun or Repetier Host.
  • Issue the command M111 S247 to enable maximum logging.
  • Perform a G28 to do your standard homing procedure.
  • Do a G29 to probe the bed. This will also enable bed leveling.
  • Save the mesh to EEPROM with the LCD or M500.

If the problem can be reproduced simply with G28 (as with RESTORE_LEVELING_AFTER_G28) then just do some G28 and G1 moves so we can see some G28 output. If the problem appears at this point, great! We have some useful info, so:

  • Paste the host log into a TXT file and drop this file into your next reply.

If you need to do other things to get the symptom to appear, please take notes and report the exact steps needed to get the Z error.

Thanks!

This is what I am testing now. Will post an output when I complete testing.

houseofbugs commented 4 years ago

I did as asked. Here is what is odd. When using G1 Z0 it looks to be the correct height. But moving down the LCD displayed value (which was 5.14mm) from octoprint or the LCD puts the nozzle 0.14mm too low.

Log file: https://pastebin.com/aVWup3Uq

houseofbugs commented 4 years ago

These look to be relevant to the issue being discussed here:

https://github.com/MarlinFirmware/Marlin/pull/15203 https://github.com/MarlinFirmware/Marlin/issues/15835

thinkyhead commented 4 years ago

Thanks for the extra data and log. I'll review it and see what portion of the code is implicated. Hopefully it will be a straightforward issue!

InsanityAutomation commented 4 years ago

At a glance, in bedleveling.cpp lines 91 and 99, functions appear to be reversed. It means one direction applies backwards and the other won't apply. Haven't had a chance to dig deeper as I've had a backed up drain in my basement to deal with today....

thinkyhead commented 4 years ago

That code is correct. The leveling correction is being applied to the current position when turning it off, and the leveling correction is being removed from the current position when turning it on. So, if the nozzle is logically at 5.0mm but the bed is actually 5.14mm below the nozzle:

Good luck with the drain!

thinkyhead commented 4 years ago

I hope it is now clear why the Z value flips between 5.0 and 5.14 when turning leveling on and off. As long as the bilinear offset at the current XY (194, 160) is in fact calculated to be -0.14 then this behavior is what you'd want.

One thing that can affect the result is Z fade, but I see in the logs that it is set to zero. Good idea, since that eliminates Z fade as being the cause of the drift.

thinkyhead commented 4 years ago

Hmm… This looks suspicious. Let's look closer at this…

ABL Adjustment Z-0.122
  current_position= X300.00 Y295.00 Z5.00 : Leveling ON
  current_position= X300.00 Y295.00 Z4.88 : ...Now OFF
  current_position= X300.00 Y295.00 Z4.88 : sync_plan_position
  current_position= X0.00 Y0.00 Z4.88 : sync_plan_position
>>> do_blocking_move_to X-450.00 Y-450.00 Z4.88

It's at the start of G28 so it probably gets canceled out, but I need to make sure it's not backward.

Ya got me all paranoid about backwardness now!

Vertabreak commented 4 years ago

your not alone in being paranoid it might be backwards that was the first idea that popped in my head also. the original report noted the issue compounded each time adding up over time but i have not seen this behavior at all. in my testing it seems to be working properly it just looks odd when the mesh data is applied. i still kinda think the real issue was hardware defect with the probe being very inaccurate that was the source of the issue i could be wrong.

thinkyhead commented 4 years ago

Ok, nevermind. It's ok. I'm now looking at Z_AFTER_PROBING which I didn't have enabled in my testing.

Vertabreak commented 4 years ago

i have Z_AFTER_PROBING 5 enabled in my fork and for my testing did not see a problem. i think we might be chasing our tails on this one. being 100% sure is a good thing.

thinkyhead commented 4 years ago

If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.

Bilinear interpolation is imperfect, and the probe offset also does matter. So there should be a bit of a slop margin considered. The firmware is convinced that the bed is 0.14mm below true zero where the nozzle is located. It is almost certain that this is wrong by some amount.

To help understand the way the mesh interacts with the Z position, can you repeat your test using a tighter grid, such as a 7x7 with ABL_BILINEAR_SUBDIVISION enabled and set to 2…?

houseofbugs commented 4 years ago

If I put the nozzle at 0 when it shows 5.16 my nozzle is grinding into my bed.

Bilinear interpolation is imperfect, and the probe offset also does matter. So there should be a bit of a slop margin considered. The firmware is convinced that the bed is 0.14mm below true zero where the nozzle is located. It is almost certain that this is wrong by some amount.

To help understand the way the mesh interacts with the Z position, can you repeat your test using a tighter grid, such as a 7x7 with ABL_BILINEAR_SUBDIVISION enabled and set to 2…?

I did that later today with a 7x7 and ABL_BILINEAR_SUBDIVISION set to 3. No change.

houseofbugs commented 4 years ago

your not alone in being paranoid it might be backwards that was the first idea that popped in my head also. the original report noted the issue compounded each time adding up over time but i have not seen this behavior at all. in my testing it seems to be working properly it just looks odd when the mesh data is applied. i still kinda think the real issue was hardware defect with the probe being very inaccurate that was the source of the issue i could be wrong.

I think the "compounding" is due to a machine issue, not firmware, I cannot replicate that. We can exclude that from the issue. That "issue" was what others said to me but I cannot replicate that. My experience is that it's always slightly off. The other issue is still present where the Z offset appears to be "drifting".

thinkyhead commented 4 years ago

I'm at the point in your video where you move Z down with the LCD and it allows Z = -0.04 (which is 0.16 minus 0.20). So I think it is being constrained in motion but Z is perhaps not being corrected in that case. If that were happening, it would be possible to keep moving down to below the bed, and the Z error would compound … -0.04, -0.08, -0.12, -0.16…

So please check and see if moving Z from the LCD with leveling on leads to anything like this.

Of course, with leveling on, Z=0 should (ideally) be just touching the bed at every point, but again this depends on a good mesh.

thinkyhead commented 4 years ago

The Z motion is constrained by the soft endstops, so depending on the Z min endstop there might be freedom to move Z below zero. But, there is no missing error correction. The constraint is done before the move is applied.

houseofbugs commented 4 years ago

I don't have the min endstops set in my firmware for the Z Min direction

houseofbugs commented 4 years ago

Took a shot in the dark after InsanityAutomation mentioned these lines. If I comment out lines 91 and 99 from bedlevel.cpp the ABL behaves as expected.

image

Z shows the correct value and when bed leveling is on (M420 S1) the Z is being adjusted when I am moving around from the LCD and USB GCode commands.

InsanityAutomation commented 4 years ago

FYI in you can monitor the creep doing nothing but G1Z5\n M420S0\nM420S1 a dozen times, then G1Z5 and look at the difference.

houseofbugs commented 4 years ago

FYI in you can monitor the creep doing nothing but G1Z5\n M420S0\nM420S1 a dozen times, then G1Z5 and look at the difference.

Is that with the lines commented out above or with them at the defaults?

InsanityAutomation commented 4 years ago

Intact at defaults

sismo99 commented 4 years ago

Hi i think i have the same issue i am not an expert but i have inconsistent z-offsets i mean i have an EZABL woriking great the standar deviation is in the range of 0.001 - 0.003 so its working well (in fact i have tried 3 diferent sensors all in the same range of standar deviation and the problem stills

i explain myself , I start a one layer gcode to calibrate and babystep my z offset, i tuned in and get a precious first layer, the print finish and save the z-offset and the try to print te exact same code and now prints to far from the bed (get separate lines) SOOO i need to recalibrate my z-offset and again i get a good first layer, and try for the third time the exact same gcode and now the nozzle is too close to the bed and need to recalibrate again and so on so every print i need to recalibarte my z Offset i tried many solutions from here but with no luck

i am using SKR Mini E3 1.2 with my own compilation of marlin bugfix 2.0.x y did the verbose logging and let my TXT file here also let my Configuration files

i really hope you can help us with this or give some ideas i will be happy to try

Configuration Files.zip Log Z Offst drifting.txt

Thanks

thinkyhead commented 4 years ago

Took a shot in the dark after InsanityAutomation mentioned these lines.

Well, that simply removes any correction when enabling/disabling leveling. It will only hide the problem, it doesn't necessarily mean this is the location, cause, or even evidence of the problem. And alas, those corrections are needed and can't just be removed.

Z shows the correct value and…

Just to be clear and reiterate:

If the mesh said "the bed has no dip at this point," then Z would remain 5.00 and moving the nozzle down to the bed would be just dandy. But the mesh data says that the bed dips there.

If this is not the case then the mesh data is wrong. Better mesh data should help.

A good trick for double-checking your probe offset is to move to the particular spot where the machine homes to establish zero and check the mesh offset at that point using G29 Q (requires DEBUG_LEVELING_FEATURE … but not M111 ...). It should be close to zero if the mesh data and bilinear interpolation are matching up well with the real bed, especially if it homes to the center.

I keep forgetting to ask, but it will help if you also paste the mesh output from M420 V along with future comments about unusual mesh offsets. And also use G29 Q liberally to see how much correction is varying over the bed. It's a good feature (though not as good as an OctoPrint plugin) for getting a picture of what bilinear interpolation thinks of your mesh data.

And of course, look at that 3x3 mesh and compare it to a 9x9 or 11x11 mesh of the same bed under the same conditions. A 3x3 mesh is too coarse to get reasonable readings of the bed height at all points. There could be a general dip from right-to-left, but at that particular spot on the bed it is relatively flat. A finer mesh is not just good for your particular heated bed, but also good … For Science!

M420 C

There's an M420 C command that will center the mesh around the mean average value (so the highest bump and lowest dip have the same magnitude). M420 C<offset> also works. But don't use this for testing mesh results. It will throw off your data. However, it can be useful for some stuff.

In particular M420 C is recommended for use along with correcting the probe Z offset. While babystepping does correct print height and can apply to the Z probe offset, it also makes the mesh data stale, so after babystepping to get a "perfect" probe offset you can just do M420 C and M500 before the next G28 and your mesh data will be caught up. Or, just do a whole new G29 as usual…

sismo99 commented 4 years ago

In particular M420 C is recommended for use along with correcting the probe Z offset. While babystepping does correct print height and can apply to the Z probe offset, it also makes the mesh data stale, so after babystepping to get a "perfect" probe offset you can just do M420 C and M500 before the next G28 and your mesh data will be caught up. Or, just do a whole new G29 as usual…

Hi and thanks for your response but as i said i am a simple user can you ellaborate more in the 420 C command, about what to de next the M500 i mean i can do the M420 C then M500 where i put it or i have to do it before every print there is a way to put it in my start gcode

I have configured my starting Gcode to make an ABL (g29) routine before each print so this is way i dont understand if this command M420 C need to do it before each print hope you or someone can help me cause this bug is very annoying becaus even calibrating te z Offset i can not get repeteable good first layers (as i said calibrate and the next need to recalibrate)

Thanks and i will post the G29 Q as soon i get it from my machine thanks

thinkyhead commented 4 years ago

I'm addressing @houseofbugs with the comments above.

sismo99 commented 4 years ago

sorry i misunderstand, but the question it still open i continue with te problem my z offset changes every print and ia have seen in 3d printing facebook groups some people have the same problem can you help us with that if there is something i can help (logs o replicateing the problem i am glad ti help

thanks in advance

thinkyhead commented 4 years ago

Remember that when you have BABYSTEP_ZPROBE_OFFSET enabled, babystepping changes your Z probe offset. As a result you must do a new G29 afterward to update the mesh for the changed height. If you skip the G29 the nozzle will be at the wrong height.

There's a catch-22 with babystepping such that we cannot adjust the mesh at the same time as adjusting the nozzle's position over the bed. In the near future we'll be exploring live mesh editing options to get a babystepping-like effect, and for 32-bit we can afford to do some other things that we held off on with AVR.

boelle commented 4 years ago

@houseofbugs has the problem by miracle been fixed when using 2.0.x bugfix ?

thinkyhead commented 4 years ago

Here's some data from my repeated G29 tests. No G28 in-between. No restore-leveling option enabled, And no Z fade. Just a bunch of probing, print out some data, and G29 again… Perhaps this has enough information to reveal some correlations.

First trial with 6x6 meshes. Not much data collected…

Cleaned Log Output ``` Repeated G29 Meshes [ +0.275, +0.163, +0.072, +0.006, -0.051, -0.087 ], [ +0.226, +0.113, +0.011, -0.014, -0.034, -0.042 ], [ +0.215, +0.095, -0.004, -0.031, -0.047, -0.041 ], [ +0.243, +0.123, +0.021, -0.009, -0.036, -0.067 ], [ +0.274, +0.136, +0.013, -0.049, -0.106, -0.142 ], [ +0.275, +0.174, +0.038, -0.031, -0.115, -0.203 ] [ +0.186, +0.080, +0.023, -0.017, -0.064, -0.089 ], [ +0.156, +0.047, -0.032, -0.051, -0.064, -0.053 ], [ +0.160, +0.045, -0.035, -0.049, -0.070, -0.059 ], [ +0.190, +0.068, -0.020, -0.047, -0.077, -0.092 ], [ +0.224, +0.083, -0.022, -0.074, -0.139, -0.174 ], [ +0.230, +0.113, -0.014, -0.087, -0.176, -0.263 ] [ +0.241, +0.142, +0.088, +0.047, +0.003, -0.022 ], [ +0.216, +0.107, +0.031, +0.016, +0.003, +0.011 ], [ +0.220, +0.108, +0.028, +0.010, -0.005, +0.006 ], [ +0.249, +0.131, +0.040, +0.015, -0.012, -0.029 ], [ +0.287, +0.147, +0.043, -0.012, -0.077, -0.111 ], [ +0.295, +0.178, +0.051, -0.024, -0.112, -0.194 ] X:319.00 Y:283.00 Z:3.26 E:0.00 Count X:25520 Y:22640 Z:1231 [ +0.374, +0.272, +0.218, +0.178, +0.129, +0.105 ], [ +0.349, +0.238, +0.161, +0.146, +0.136, +0.144 ], [ +0.356, +0.238, +0.158, +0.142, +0.124, +0.136 ], [ +0.384, +0.263, +0.176, +0.150, +0.119, +0.103 ], [ +0.421, +0.278, +0.175, +0.121, +0.059, +0.022 ], [ +0.426, +0.310, +0.183, +0.113, +0.023, -0.065 ] X:319.00 Y:283.00 Z:3.32 E:0.00 Count X:25520 Y:22640 Z:1275 [ +0.525, +0.428, +0.371, +0.329, +0.286, +0.261 ], [ +0.500, +0.395, +0.316, +0.301, +0.286, +0.295 ], [ +0.506, +0.393, +0.313, +0.295, +0.279, +0.293 ], [ +0.533, +0.415, +0.328, +0.300, +0.272, +0.259 ], [ +0.571, +0.433, +0.329, +0.272, +0.212, +0.178 ], [ +0.577, +0.459, +0.334, +0.263, +0.176, +0.088 ] X:319.00 Y:283.00 Z:3.34 E:0.00 Count X:25520 Y:22640 Z:1320 [ +0.650, +0.548, +0.492, +0.451, +0.408, +0.384 ], [ +0.623, +0.516, +0.436, +0.420, +0.407, +0.421 ], [ +0.630, +0.513, +0.433, +0.418, +0.403, +0.413 ], [ +0.654, +0.533, +0.447, +0.423, +0.392, +0.380 ], [ +0.692, +0.553, +0.447, +0.398, +0.332, +0.298 ], [ +0.698, +0.581, +0.454, +0.386, +0.295, +0.213 ] X:319.00 Y:283.00 Z:3.31 E:0.00 Count X:25520 Y:22640 Z:1348 [ +0.703, +0.600, +0.544, +0.503, +0.458, +0.435 ], [ +0.676, +0.571, +0.495, +0.481, +0.466, +0.477 ], [ +0.687, +0.573, +0.493, +0.477, +0.458, +0.475 ], [ +0.709, +0.594, +0.508, +0.484, +0.456, +0.441 ], [ +0.757, +0.613, +0.510, +0.461, +0.395, +0.364 ], [ +0.763, +0.646, +0.521, +0.448, +0.356, +0.275 ] X:319.00 Y:283.00 Z:3.25 E:0.00 Count X:25520 Y:22640 Z:1357 ```

Next trial. Much quicker 3x3 meshes. These show a less pronounced shift, but it is there.

--> STEPS PER MM: M92 X80.00 Y80.00 Z400.00 E95.00  (Each Z step is 0.0025mm)
--> ~~`RESTORE_LEVELING_AFTER_G28`~~ is DISABLED
--> Z Fade OFF
--> Probe Offset Z-0.16
Cleaned Log Output ``` G28 Recv: Logical: X:198.000 Y:155.000 Z:0.160 Recv: Raw: X:198.000 Y:155.000 Z:0.160 Recv: Leveled: X:198.000 Y:155.000 Z:0.160 Recv: UnLevel: X:198.000 Y:155.000 Z:0.160 Recv: Stepper: X:15840 Y:12400 Z:64 E:0 Recv: FromStp: X:198.000 Y:155.000 Z:0.160 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 G29 =============================================================== Recv: [ +0.204, +0.024, -0.065 ], Recv: [ +0.197, -0.029, -0.059 ], Recv: [ +0.251, -0.027, -0.248 ] Recv: G29 uncorrected Z:2.94 Recv: corrected Z:3.19 Recv: current_position= X319.00 Y283.00 Z3.19 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.19 E:0.00 Count X:25520 Y:22640 Z:1176 Recv: Logical: X:319.000 Y:283.000 Z:3.188 Recv: Raw: X:319.000 Y:283.000 Z:3.188 Recv: Leveled: X:319.000 Y:283.000 Z:2.940 Recv: UnLevel: X:319.000 Y:283.000 Z:3.188 Recv: Stepper: X:25520 Y:22640 Z:1176 E:0 Recv: FromStp: X:319.000 Y:283.000 Z:2.940 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:-0.000 E:0.000 Recv: ABL Adjustment Z-0.248 G29 =============================================================== Recv: [ +0.193, +0.015, -0.069 ], Recv: [ +0.186, -0.034, -0.061 ], Recv: [ +0.243, -0.038, -0.252 ] (-0.008) Recv: G29 uncorrected Z:2.93 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1174 Recv: Logical: X:319.000 Y:283.000 Z:3.183 Recv: Raw: X:319.000 Y:283.000 Z:3.183 Recv: Leveled: X:319.000 Y:283.000 Z:2.935 (-0.005) Recv: UnLevel: X:319.000 Y:283.000 Z:3.183 Recv: Stepper: X:25520 Y:22640 Z:1174 E:0 (-2) Recv: FromStp: X:319.000 Y:283.000 Z:2.935 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.248 (0.000) G29 =============================================================== Recv: [ +0.188, +0.008, -0.077 ], Recv: [ +0.178, -0.042, -0.071 ], Recv: [ +0.238, -0.045, -0.257 ] (-0.005) Recv: G29 uncorrected Z:2.93 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1172 Recv: Logical: X:319.000 Y:283.000 Z:3.182 Recv: Raw: X:319.000 Y:283.000 Z:3.182 Recv: Leveled: X:319.000 Y:283.000 Z:2.930 (-0.005) Recv: UnLevel: X:319.000 Y:283.000 Z:3.182 Recv: Stepper: X:25520 Y:22640 Z:1172 E:0 (-2) Recv: FromStp: X:319.000 Y:283.000 Z:2.930 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:-0.000 E:0.000 Recv: ABL Adjustment Z-0.252 (-0.014) G29 =============================================================== Recv: [ +0.174, -0.008, -0.089 ], Recv: [ +0.163, -0.056, -0.082 ], Recv: [ +0.223, -0.058, -0.272 ] (-0.015) Recv: G29 uncorrected Z:2.91 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1166 Recv: Logical: X:319.000 Y:283.000 Z:3.179 Recv: Raw: X:319.000 Y:283.000 Z:3.179 Recv: Leveled: X:319.000 Y:283.000 Z:2.915 (-0.015) Recv: UnLevel: X:319.000 Y:283.000 Z:3.179 Recv: Stepper: X:25520 Y:22640 Z:1166 E:0 (-6) Recv: FromStp: X:319.000 Y:283.000 Z:2.915 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.264 (-0.012) G29 =============================================================== Recv: current_position= X319.00 Y283.00 Z3.18 : Leveling ON Recv: current_position= X319.00 Y283.00 Z2.91 : ...Now OFF (-0.27) Recv: [ +0.166, -0.017, -0.099 ], Recv: [ +0.156, -0.067, -0.093 ], Recv: [ +0.215, -0.069, -0.282 ] (-0.008) Recv: G29 uncorrected Z:2.90 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1162 Recv: Logical: X:319.000 Y:283.000 Z:3.177 Recv: Raw: X:319.000 Y:283.000 Z:3.177 Recv: Leveled: X:319.000 Y:283.000 Z:2.905 (-0.010) Recv: UnLevel: X:319.000 Y:283.000 Z:3.177 Recv: Stepper: X:25520 Y:22640 Z:1162 E:0 (-4) Recv: FromStp: X:319.000 Y:283.000 Z:2.905 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.272 (-0.008) G29 =============================================================== Recv: current_position= X319.00 Y283.00 Z3.18 : Leveling ON Recv: current_position= X319.00 Y283.00 Z2.89 : ...Now OFF (-0.29) Recv: [ +0.151, -0.029, -0.111 ], Recv: [ +0.141, -0.080, -0.104 ], Recv: [ +0.201, -0.082, -0.293 ] (-0.014) Recv: G29 uncorrected Z:2.89 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1158 Recv: Logical: X:319.000 Y:283.000 Z:3.177 Recv: Raw: X:319.000 Y:283.000 Z:3.177 Recv: Leveled: X:319.000 Y:283.000 Z:2.895 (-0.010) Recv: UnLevel: X:319.000 Y:283.000 Z:3.177 Recv: Stepper: X:25520 Y:22640 Z:1158 E:0 (-4) Recv: FromStp: X:319.000 Y:283.000 Z:2.895 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.282 (-0.011) G29 =============================================================== Recv: current_position= X319.00 Y283.00 Z3.18 : Leveling ON Recv: current_position= X319.00 Y283.00 Z2.88 : ...Now OFF (-0.30) Recv: [ +0.139, -0.041, -0.124 ], (-0.012, -0.012, -0.013) Recv: [ +0.131, -0.089, -0.116 ], (-0.010, -0.009, -0.012) Recv: [ +0.190, -0.094, -0.306 ] (-0.011, -0.012, -0.013) Recv: G29 uncorrected Z:2.88 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1153 Recv: Logical: X:319.000 Y:283.000 Z:3.175 Recv: Raw: X:319.000 Y:283.000 Z:3.175 Recv: Leveled: X:319.000 Y:283.000 Z:2.882 (-0.013) Recv: UnLevel: X:319.000 Y:283.000 Z:3.175 Recv: Stepper: X:25520 Y:22640 Z:1153 E:0 (-5) Recv: FromStp: X:319.000 Y:283.000 Z:2.882 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.293 (-0.011) G29 =============================================================== Recv: current_position= X319.00 Y283.00 Z3.18 : Leveling ON Recv: current_position= X319.00 Y283.00 Z2.87 : ...Now OFF (-0.31) Recv: [ +0.127, -0.054, -0.138 ], (-0.012, -0.013, -0.014) Recv: [ +0.113, -0.103, -0.132 ], (-0.018, -0.014, -0.016) Recv: [ +0.174, -0.106, -0.319 ] (-0.016, -0.012, -0.013) Recv: G29 uncorrected Z:2.87 Recv: corrected Z:3.18 Recv: current_position= X319.00 Y283.00 Z3.18 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.18 E:0.00 Count X:25520 Y:22640 Z:1148 Recv: Logical: X:319.000 Y:283.000 Z:3.176 Recv: Raw: X:319.000 Y:283.000 Z:3.176 Recv: Leveled: X:319.000 Y:283.000 Z:2.870 (-0.012) Recv: UnLevel: X:319.000 Y:283.000 Z:3.176 Recv: Stepper: X:25520 Y:22640 Z:1148 E:0 (-5) Recv: FromStp: X:319.000 Y:283.000 Z:2.870 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.307 (-0.014) G29 =============================================================== Recv: current_position= X319.00 Y283.00 Z3.18 : Leveling ON Recv: current_position= X319.00 Y283.00 Z2.86 : ...Now OFF (-0.32) Recv: [ +0.111, -0.069, -0.154 ], Recv: [ +0.098, -0.119, -0.146 ], Recv: [ +0.160, -0.125, -0.334 ] (-0.014) Recv: G29 uncorrected Z:2.85 Recv: corrected Z:3.17 (+0.32) Recv: current_position= X319.00 Y283.00 Z3.17 : sync_plan_position Recv: X:319.00 Y:283.00 Z:3.17 E:0.00 Count X:25520 Y:22640 Z:1141 Recv: Logical: X:319.000 Y:283.000 Z:3.171 Recv: Raw: X:319.000 Y:283.000 Z:3.171 Recv: Leveled: X:319.000 Y:283.000 Z:2.852 (-0.018) Recv: UnLevel: X:319.000 Y:283.000 Z:3.171 Recv: Stepper: X:25520 Y:22640 Z:1141 E:0 (-7) Recv: FromStp: X:319.000 Y:283.000 Z:2.852 E:0.000 Recv: Diff: X:0.000 Y:0.000 Z:0.000 E:0.000 Recv: ABL Adjustment Z-0.319 (-0.012) ```
TheAdminFrmoHell commented 4 years ago

is this fixed?

fiftythree33 commented 4 years ago

I think I am experiencing this issue on my printer. It will be tomorrow evening before I can complete any further testing and provide logs but it appears in both 2.0.bugfix from 7/20/19 and in 2.0.4.4. I upgraded because of issues with bed leveling. I also have to disable stealthchop to get accurate probing, is that a known issue? Should I compile a new build with current bugfix for testing or stay on 2.0.4.4?

houseofbugs commented 4 years ago

@houseofbugs has the problem by miracle been fixed when using 2.0.x bugfix ?

Haven't had a chance to test yet.

baracoder commented 4 years ago

I am having a similar issue when using M851 (probe offset) and bed leveling (bilinear or UBL both are affected) and RESTORE_LEVELING_AFTER_G28 The z-offset was random, after every so minor change of the z-offset. After three days of pulling my hair out, the workaround was to explicitly enable bed leveling after G28 using M420 S. This behaves as expected, even with RESTORE_LEVELING_AFTER_G28 still enabled

boelle commented 4 years ago

@houseofbugs still an issue?

boelle commented 4 years ago

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

github-actions[bot] commented 4 years ago

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