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 probe offset isn't working #22322

Closed CMcKenzie74 closed 3 months ago

CMcKenzie74 commented 3 years ago

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

  1. I run a bed level using BLTouch and store setting.
  2. do a test print and use babystepping to find the z probe offset.
  3. put the value from previous step into the z probe offset under configuration and store setting.
  4. when doing a print after these steps the z probe offset seems to be ignored and I have to run through step 2 again.
  5. if i power off the printer the prints seem to work fine unless I run another bed level which forces me to run through step 2 again and the z probe offset value keeps getting bigger. My Marlin setup files.zip

Bug Timeline

new I have just upgradded my ender 3 Max with a BTT E3 turbo and BL Touch

Expected behavior

I expected the setting for the Z probe to stay in config and retain it for every print even after a g29.

Actual behavior

the z probe offset seems to be ignored.

Steps to Reproduce

1 run a bed level procedure (g29). 2 run a print.

Version of Marlin Firmware

bugfix-2.0.x downloaded 09\07\21

Printer model

creality ender 3 Max

Electronics

BTT e3 turbo board

Add-ons

BL Touch

Your Slicer

Cura

Host Software

SD Card (headless)

Additional information & file uploads

No response

DiskDoctor commented 2 years ago

Any response to the additional info I posted above to help isolate the bug? I can upload configurations if desired

JeremyDWilliams commented 2 years ago

When soft endstop for Z is enabled, any command to move below ZERO is stopped at 0, or G28 or simply Z home is resetting Z zero point without including negative z probe offset<

This sounds like a possible suspect.

It's as if the offset amount just isn't getting to where it needs to go, or the wrong (old) variable is being passed.

I was honestly about to ask if UBL was still supported or if it was abandoned, but figured I'd get my head bit off... until I saw this post after hours of searching. I'm glad it's still being supported, but I've gone from having a working machine to one that I can't get to print. (sigh).

The documentation didn't help as it doesn't really explain the correct and full procedure to obtain and enter the correct z probe offset and how to use UBL, or the wizard.

It ignores z offset. It keeps printing about 1.5mm above the bed. It doesn't seem to matter what I enter for the offset. I always get the same printing in space (1.5mm).

During a test to see if turning off soft endstops with the LCD menu, it had no affect. And curiously hitting pause during a test print dropped it into "stop" print, not pause. And the print was fully cancelled.

I also tried adding G29 to gcode to see if that would 'wake up the mesh and z offset, but nope. My initial assumption was that I would not need any special (or new, additional) gcode to let UBL work.

I did try using the wizard, which ended up spending 15 minutes doing nothing while displaying 'printing' complete with minutes to go. This after forcing me to go through a empty/load filament cycle that emptied a half meter or filament on the bed while I have 100mm in the config.h file.

I mention this other stuff, not as a definitive smoking gun, but as hopefully a clue that some other items may be involved.

Regardless, I do appreciate any and all help I can get to fix this.

As I've already put more time into this than I care to admit, I would be happy to help improve documentation and/or try to help find the cause of this bug (or user error causing this problem)

ManuelMcLure commented 2 years ago

A couple of questions:

If it's connected to the probe port and it is easy to do (i.e. the black/white wire from the probe is separate from the servo wire) try switching to the Z min port and enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and see if that fixes it. If it isn't easy to move the probe to Z min you can edit the pins file for your board and swap the Z min and probe pins instead of physically switching it. In either case enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN. There's some weirdness involving the dedicated probe port that strikes some users and not others.

Just to ensure clarity on what's expected when homing with a Z offset, after homing Z the nozzle should move up Z_AFTER_HOMING mm (default 10) and should display on the LCD the value of Z_AFTER_HOMING minus your configured probe offset (as displayed by M851). For example, if your Z probe offset is -1.77 then the Z should show 11.7 after homing.

JeremyDWilliams commented 2 years ago

A couple of questions:

  • Are you homing with the probe, or with a separate end stop?
  • If homing with the probe, do you have it connected to the dedicated probe port or to the Z min end stop port?

1) Homing with the probe (BL touch v3.1)

2) The probe is connected to the probe port (not the 2 wire Z stop) on the BTT SKR Mini E3 V3

I will try as you suggest.

And yes, the auto homing shows 10mm minus the negative offset (10mm - (-1.3) = 11.3mm displayed Z height after homing

ManuelMcLure commented 2 years ago

OK - another couple of questions:

JeremyDWilliams commented 2 years ago

OK - another couple of questions:

  • If after homing, you move Z to Z=0, is the nozzle at the right place (i.e. almost touching the bed)?
  • Was the UBL mesh generated before or after the probe offset was set up? The measurement in the mesh point nearest the Z safe homing point should be very close to 0. If it isn't, you should try rebuilding the mesh with the new Z offset configured.

1) yes 2) I have tried both, before and after with no notable difference. At the center of the bed, where it z-homes, the value is Z: 0.052

And a huge THANK YOU! for helping.

I will do the items above as soon as possible... it might be an hour or so.

DiskDoctor commented 2 years ago

If it's connected to the probe port and it is easy to do (i.e. the black/white wire from the probe is separate from the servo wire) try switching to the Z min port and enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and see if that fixes it. If it isn't easy to move the probe to Z min you can edit the pins file for your board and swap the Z min and probe pins instead of physically switching it. In either case enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN. There's some weirdness involving the dedicated probe port that strikes some users and not others.

This was in the back of my mind, too. It should make zero difference, but this problem should not exist, either.

My goal is to get the z-homing working properly, then use slicer (Cura for now) to set Z-offset for variable first layer thickness.

I expect to be testing UBL this weekend, which is supposed to not have this problem.

As long as we keep working this problem, something will turn out.

I wonder if there is a particular combination of settings causing this incorrect behavior or messing with the variables?

DiskDoctor commented 2 years ago
  • If after homing, you move Z to Z=0, is the nozzle at the right place (i.e. almost touching the bed)?

Negative on mine. The nozzle is too high and won't move below that point (Z0), until printing.

I could try enabling Babysteps everywhere and experimental, but trying to keep it simple and that would be a workaround, not a solution.

Important to note: Before running z offset wizard, be sure to set z offset to 0.00 and store the settings. Otherwise it just all adds together, which also seems incorrect behavior.

midnightsmith89 commented 2 years ago

I can confirm same issues here, but using an SKR 1.3 board, constant adjustment of the offset for every print is needed. Attached is my config. Note this happens on my TRONXY machine as well, using an SKR 1.4 board. I have ran through all suggestions here to the same results. Something is changing the Z home position, because the offset value persists, but is now wrong after each home or print. Marlin.zip

linuxsense commented 2 years ago

I have the same issue with a SKR 1.4 Turbo. It will be fine then for some reason it just starts to ignore the probe offset. If I re-flash it will be fine untill suddenly it isn't.

GJSchaller commented 2 years ago

For what it's worth, I turned off the Probe Offset Wizard and haven't had any issues. Once I set the value by hand on the printer or in the firmware, it seems stable. I did notice that my offset somehow changed from -1.85 to -2.85, but once I set it, it's been fine ever since.

midnightsmith89 commented 2 years ago

I have the same issue with a SKR 1.4 Turbo. It will be fine then for some reason it just starts to ignore the probe offset. If I re-flash it will be fine untill suddenly it isn't.

So much this! a fresh install works for an undetermined length of time, until suddenly it doesnt!

DiskDoctor commented 2 years ago

Start this video here and see how the z-offset can be done via command line. Notice he turns off soft endstops while setting. I haven't tried this procedure to test if it holds the offset yet. https://youtu.be/ONpKxkil16Q?t=605 What results is anyone seeing if you follow these steps?

ManuelMcLure commented 2 years ago

If the offset is being lost, it might be something wrong with your EEPROM. First, make sure that the setting of NOZZLE_TO_PROBE_OFFSET is correct in your Configuration.h. Then upload the firmware and do M502/M500 to ensure the offset is stored correctly in EEPROM. Then if you start seeing the problem again, do M851 and see if the value is still correct - if it isn't then something's clobbering EEPROM. If so, you should be able to just do another M502/M500 to get back the value from firmware.

linuxsense commented 2 years ago

For what it's worth, I turned off the Probe Offset Wizard and haven't had any issues. Once I set the value by hand on the printer or in the firmware, it seems stable. I did notice that my offset somehow changed from -1.85 to -2.85, but once I set it, it's been fine ever since.

That's an interesting point. I cant say with 100% certainty but I think this happened only after building firmware with that option enabled. That includes 2.0.9.3 (last non-bugfix). I am going to remove that option and see if my default is held.

midnightsmith89 commented 2 years ago

If the offset is being lost, it might be something wrong with your EEPROM. First, make sure that the setting of NOZZLE_TO_PROBE_OFFSET is correct in your Configuration.h. Then upload the firmware and do M502/M500 to ensure the offset is stored correctly in EEPROM. Then if you start seeing the problem again, do M851 and see if the value is still correct - if it isn't then something's clobbering EEPROM. If so, you should be able to just do another M502/M500 to get back the value from firmware.

The offset in eeprom stays the same. M502 does not solve the issue though, as it needs to be re adjusted up or down after each print regardless what its set to.

In response to others, I dont even use the offset wizard, never have. So I'll also see about disabling and trying, not sure when this became enabled by default. I always start a print (chep bed level) and babystep down till its good, then store that value as the offset.

sjscicluna83 commented 2 years ago

I'm having the same issue I have an anycubic 13 mega with SKR1.4 turbo that has dual z motors dual z end-stops and an IR Z probe just for leveling the bed.

I was running 2.0.6.0 and bed leveling worked but did manual z offset I upgraded the config over to 2.0.9.3 for the z offset wizard but got the same errors as everyone else. The funny thing is when I ran the Zoffset wizard for the first time there was a 0.01 difference from what I manually measured from firmware 2.0.6 so I know it is measuring correctly. after I ran a bed level after the z probe offset i was printing in the air and after each subsequent bed level, it got closer and closer till it was smashing the bed. i have since gone back to 2.0.6.0 and all is fine in the world.

I can post my configs if needed and do further testing if needed but I guess manual z offset is for me for now till this gets fixed.

midnightsmith89 commented 2 years ago

I have not yet tested the removal of offset wizard, but i never use it anyways, so shouldnt hurt to take it off. I run a single layer print over the bed (CHEP bed level square) and baby step down as it goes to find a good offset. Also, looking at Marlin development, looks like there's only 10 really active devs, with Tinkyhead being the most active.

JeremyDWilliams commented 2 years ago

I'm convinced this is an issue with a variable being passed incorrectly.

A new issue popped up out of the blue. The Z axis stepper started to vibrate without moving while being sent a command to move. After re-installing non-modified Marlin bug fix, normal Z motor functionality resumed.

Also of note, I did previously install the x offset wizard, but it wasn't in my menu.

I'm going to try using bilevel instead to see if it works.

Then I will make changes to Marlin until it doesn't work again. (Assuming bilevel works)

ManuelMcLure commented 2 years ago

"The Z axis stepper started to vibrate without moving while being sent a command to move."

That might be a wiring issue. It might be completely coincidental that when you changed the version of Marlin the Z behavior changed. A wiring issue would also explain the fact that the Z offset is changing if it's causing Z to randomly lose steps.

If it isn't wiring, then it sounds like maybe feedrates are getting clobbered somehow so the axis is trying to move too fast - that's another thing that can cause that sort of behavior.

JeremyDWilliams commented 2 years ago

"The Z axis stepper started to vibrate without moving while being sent a command to move."

That might be a wiring issue. It might be completely coincidental that when you changed the version of Marlin the Z behavior changed. A wiring issue would also explain the fact that the Z offset is changing if it's causing Z to randomly lose steps.

If it isn't wiring, then it sounds like maybe feedrates are getting clobbered somehow so the axis is trying to move too fast - that's another thing that can cause that sort of behavior.

You were completely correct on this! With all the fussing about trying different things (as suggested by others), the Z stepper connector had become lose enough that not all connectors were fully connected. It looked connected - but wasn't fully.

While working on another printer using a different auto-level firmware, I had similar problems. It was an easy fix though, the proximity sensor was too high (or the nozzle too low, take your pick). I don't think this is the case here as the nozzle is between the upper and lower limits of the BL touch. But I will lower it physically to see if that is part of the problem.

And thank you!

reicaden commented 2 years ago

In response to others, I dont even use the offset wizard, never have. So I'll also see about disabling and trying, not sure when this became enabled by default. I always start a print (chep bed level) and babystep down till its good, then store that value as the offset.

Im having the same issue. I did not use the offset wizard, in fact I never undefined it in the firmware... its still marked to not be active. I do exactly what is described above, but the next print is always with the nozzle too high.... I adjust down and resave the EPROMM setting.... next print, once again, too high? And again and again and again. Ive gone as high as -12.750 after 8 prints.

Did anyone find a work around? Does recompile work or would it be the same issue?

Ender 5, CRTouch, SKR 3.1 board, marlin 2.0

If anyone has found a solution, that would be amazing.... if recompile and reflash works, ill do that. Just tired of having to manually adjust an additional -1.50 or so, for every single print.

richardtreier commented 2 years ago

This issue still persists. I'm using an Ender 3 V4.2.2 board with a BL Touch (5 pin) and TH3D UFW.

Also:

thisiskeithb commented 2 years ago

I'm using an Ender 3 V4.2.2 board with a BL Touch (5 pin) and TH3D UFW.

You’ll need to contact TH3D. We don’t support forks of Marlin.

midnightsmith89 commented 2 years ago

So I disabled the offset configuration wizard, and I'm about 30 prints in with no need to reset the offset. Now, it's still not compensating enough, far right side is still more squished than the far left, but it stays consistent. So perhaps the bug is in the offset wizard?

JeremyDWilliams commented 2 years ago

So I disabled the offset configuration wizard, and I'm about 30 prints in with no need to reset the offset. Now, it's still not compensating enough, far right side is still more squished than the far left, but it stays consistent. So perhaps the bug is in the offset wizard?

I just want to be clear.. are you using a Marlin release? or a fork of Marlin (TH3D UFW)? And if Marlin, UBL (Universal Bed Leveling) or ABL, MBL?

I ended up parking the printer for the last few months and using other ones. I will try the new 2.1 release on it in case something changed to fix the issue.

midnightsmith89 commented 2 years ago

This is Marlin 2.1 with the offset wizard disabled. Using bilinear bed leveling. I don't touch other precompiled firmwares as they are unsupported by Marlin devs.

Gatts011 commented 2 years ago

Still an issue, lost all faith in my build skills until finding this gem. Went through many, many probe iterations. Also, setting probe to manual + deploy confirmation, wizard will break when asking for confirmation (nav's away from wizard menu). Not complaining... love your work!

Ant264 commented 2 years ago

I can't confirm the exact combination of settings that causes this issue, when I get some time I'll try figure it out. I solved it by copying over settings from Minimal 3DP (YT) firmware .

moham96 commented 2 years ago

Seriously, my printer has been collecting dust for more than a year because of this issue, is this ever going to be solved

Gatts011 commented 2 years ago

Managed to find my idea offset setting manually, then try print, then subtract(more negative) babysteps needed. Be sure to store and reload when testing. I also powered down everything and restart to confirm im hitting the same height.

ghost commented 1 year ago

I'm also running in to this issue running the latest (as of 24/10/22) 2.1.x bugfix version. Seems that the Z probe offset is beeing ignored, ran the same flow as @richardtreier described, lowering the Z probe offset every time, but after homing (G28) and moving the Z axis to 0 the it's once again the same offset (4,25 in my case) above the bed

Gatts011 commented 1 year ago

I'm also running in to this issue running the latest (as of 24/10/22) 2.1.x bugfix version. Seems that the Z probe offset is beeing ignored, ran the same flow as @richardtreier described, lowering the Z probe offset every time, but after homing (G28) and moving the Z axis to 0 the it's once again the same offset (4,25 in my case) above the bed

Make sure to "store settings" then "load settings" after setting offset... there are mcodes for that but I just use LCD. Let me know if that helps??

BalloonBoltee commented 1 year ago

Hello everyone, first of all thank you very much for keeping Marlin as a very awesome platform updated and keep developing it.

I am running into the same issues as mentioned above, so that i cannot set Z Endstop offsets, which would be respected after homing. I am using three Z Sensors (one for each of the two Z Steppers per side for independent homing, and one manually magnetically attached switch based Sensor for bed probing).

Only way to break the physical limit switch boundaries is by turning off the soft endstops.

I can set a home offset, which is saved, restored and shown in the actual Z Position feedback (e.g. an offset of -2mm on Z Axis). Position Feedback on Z Axis, when driving into the soft Endstops is +2mm - as it should be. But no possibility to hit the 0mm mark.

I tried Marlin 2.1.1 and 2.0.6 - both do show the same behaviour.

Maybe someone can help, i'd be more than happy to supply more Inormation if needed.

Thank you!

Dummy-up commented 1 year ago

This issue still persists. I'm using an Ender 3 V4.2.2 board with a BL Touch (5 pin) and TH3D UFW.

I have absolutely identical issue. Thank you for posting, working on this at 2am here and not sure if I am going mad but clearly a bug. Already wrecked a PEI bed: it is the illogical and unpredictable nature of the changes in Z offset that result in th nozzle going from a good several mm above the bed to apparently trying to sink an oil well in my $50 magnetic bed, and can happen when the offset is reduced FFS! I understand TH3D is a proprietary fork but the symptoms are so similar that when the Marlin issue is sorted i would stake my nuts on the solution for the Unified 2 fw being the same.

You won't get any joy from TH3D unless you are a paying customer, and I don't need an EAZBL so forums are your friend..

JeremyDWilliams commented 1 year ago

This issue still persists. I'm using an Ender 3 V4.2.2 board with a BL Touch (5 pin) and TH3D UFW.

You won't get any joy from TH3D unless you are a paying customer, and I don't need an EAZBL so forums are your friend..

After another many months hiatus from this... I decided to see if any updates from this. I get it...Marlin crew don't support forks. OK. So what is the solution? One could argue that every single instance is a fork at some level.

If Marlin is made to work on many machines/setups then why not this?

I really wish someone who understands Marlin at its core would throw a bone. Anything.

So if this fork is dead, what is the alternative to get back on the main highway?

I'm convinced that an old piece of code is lurking in the background overriding settings for this. Why else would this keep glitching?

I've got this great Ender3 with a BL touch, Direct drive, SKR mini E3 v3 etc. and..... apart from collecting dust, its useless. Seriously considering just reverting to an old board that is supported. Makes no sense to me... but I'm pretty well lost in the desert on this one (as are many above)

I've got other printers thankfully. Shame though that a little more help from those in the know couldn't be dropped here. It would really help :)

JeremyDWilliams commented 1 year ago

I'm also running in to this issue running the latest (as of 24/10/22) 2.1.x bugfix version. Seems that the Z probe offset is beeing ignored, ran the same flow as @richardtreier described, lowering the Z probe offset every time, but after homing (G28) and moving the Z axis to 0 the it's once again the same offset (4,25 in my case) above the bed

Make sure to "store settings" then "load settings" after setting offset... there are mcodes for that but I just use LCD. Let me know if that helps??

You can do all that (or at least I have done) and it seems to erase that and go back to whatever it thinks it should be (which is incorrect). How hard is it to look at the actual code behind marlin? Someway to step through the code to see where Marlin is getting these erroneous values?

richardtreier commented 1 year ago

@Dummy-up @JeremyDWilliams

While never truly resolving the issue, here's my current workaround:

I am still using the same hardware.

blast-hardcheese commented 1 year ago

I have this issue with the stock Ender 5 Pro 4.2.2 board, I've tried to dig in but I haven't had a tremendous amount of luck. Creality's stock firmware either has filament runout sensing or BLTouch, which would be funny if it wasn't so frustrating.

plundrigan commented 1 year ago

I have been experiencing this issue big time with the CR Touch and the Ender 3 pro 4.2.7 board and I started with Creality firmware with CR Touch support. I have compiled the Marlin build Marlin BugFix 2.1.x.

I tried everything everyone else did. Here was something interesting I noticed and am curious if others notice it.

When I home my device from the Standard LCD menu. My display says the head is at 5 however, if I drop the head down by 5mm I am still short of the bed by 5mm. Meaning that instead of registering 10 when homed it registers 5, then when I use the wizard or z offset. I am trying to compensate for 10 mm but in reality it should be 5. This could be just me but I thought I would toss this out there in case others notice this phenomenon. I am at my wits end. I had a couple of great print runs, then had to turn it off because it locked up and whamo, print head in the bed.

blast-hardcheese commented 1 year ago

Reading through the code, there's a different code path when babystepping is enabled vs not. I wonder if the Z-offset could just be compensated with baby stepping entirely, or if disabling babystepping would produce a more favorable result. I haven't had a chance to test this

GJSchaller commented 1 year ago

I disabled (did not enable) Babystepping, and the issue cleared up for me. It didn't occur this was the case until @blast-hardcheese noted it, and I realized the problem had stopped occurring. We'd need to verify this, but I think that is a very good lead.

plundrigan commented 1 year ago

Question, that may be on or off topic. If we have a BL or CR touch and use home/bed leveling should it not detect the z-offset automatically. The sensor drop and brings and triggers to raise when probably at the right level for good squish. If it is then a little off then baby stepping would adjust the smidge more to become spot on.

I got very frustrated last night so I shut off the machine. When it came on the nozzle looked to be about 10mm off the bed and the display reflected the same. I hit home and the cr touch deployed twice the nozzle rested at 10mm but the display stated 5. I will try turning off baby-stepping.

EDIT: Turned off baby-stepping same issues for me.

blast-hardcheese commented 1 year ago

I've also tried turning off babystepping and Z-offset did not address this issue.

What did work, however painful, was to sit there in Octoapp during the purge line and frantically mash Babystep -0.01 until I got the nozzle close to the bed, at which point I was able to successfully test print.

I've tried putting M290 Z-2.4 as a step in the gcode after I level the bed but before the first layer, but unfortunately that does not seem to be interpreted correctly when printed from Octoprint. Putting the exact same gcode on the TF card and printing directly from the printer correctly interpreted M290 and adjusted the bed height accordingly.

blast-hardcheese commented 1 year ago

OK! A real workaround! I was able to use M206 Z2.4 after G28 in the PrusaSlicer settings for my printer, and even using Octoprint the gcode is now successfully printing!

This is not a solution to the problem, only a workaround but at least I can print!

I'm currently on bugfix-2.1.x, which at the time of writing is c209626bda.

Dummy-up commented 1 year ago

This is all very helpful for me as a beginner to the world of firmware tweaks and annoyances. I am just starting to understand that mesh is a thing that is integral to bed levelling, as i had been pretty much ignoring it. I wish someone could explain its role in z offset and bed levelling as the information on line does not seem to talk about mesh outside of theory in relation to printing models as opposed to settings prior to printing if that makes sense.

But more important to me than in depth knowledge of theory is how to get this consumer item working, and this information is a good start. With relationg ot blash-hardcheese 's post, I use Cura, so I just enter this into the printer settings before or after G29 or instead of the line M206 Z2.4? And then its perfect PETG and ABS prints for ever? :) Is that right? All my Pis are too old for octoprint and I don't want to shell out AUD 350 for a new one.

plundrigan commented 1 year ago

I was able to adjust

define Z_AFTER_HOMING 10 // (mm) Height to move to after homing Z. That seems to allow me to be more consistent with using the z-offset wizard. I am back to printing again.

I am like @Dummy-up I have not gotten all the G Codes down yet. I wonder this this too should be enabled and set to 10 as well for consistency. Or is this setting only raising z for during the bed level process and each test in the mesh. //#define Z_AFTER_PROBING 5 // Z position after probing is done Not sure if the default is 5 since it is not enabled.

EDIT: I have only changed the #define Z_AFTER_HOMING 10 with a z-offest of -1 in my case and with stored settings and multiple off and on cycles of my printer each time. I can load a file from SD and just start printing again. I have made sure my Slicer in custom G-Code is doing a G28 followed by a G29. So while start up of each new job takes a little to home and level the bed. I do not have to mess about with the z-offset everytime.

blast-hardcheese commented 1 year ago

Since my last post I haven't been able to jump back into the source, but the combination of M206 got me started, but then it turns out that babystepping alone seems to be preserved between prints, so provided I don't shut the printer down babystepping alone seems to have worked well and produced consistent results.

I still intend to get to the bottom of why the Z offset isn't reflected as desired, but hopefully some may be able to get their printers working again with these workarounds

mrboston911 commented 1 year ago

Glad to see i'm not the only one smashing his head on this desk wondering why it did work but now it doesnt.

mrboston911 commented 1 year ago

This is what worked for me.

Use "M851 Z0" to reset the Z offset. Home the printer with "G28". Your LCD should show Z=0 at this point. Execute "M121" to disable hardware endstops, and "M211 S0" to disable software endstops. Jog the Z axis down with your LCD until the nozzle just grabs a piece of paper. The LCD should show Z as a negative number, for example Z=-2.1 Run "M851 Zwhatever you measured" - for the example above use "M851 Z-2.1" Home the printer again with "G28". The nozzle should end up at the same location as before but the Z on the LCD should read the negative of whatever you set for M851 (for example Z=2.1) Execute "G0 Z0" and the nozzle should just grab a piece of paper and the LCD should show Z=0 Save the value with M500, and copy it into your Configuration.h.

Props to [MMcLure] (https://reprap.org/forum/profile.php?262,71092)