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] Incorrect Z position after Auto Bed Leveling (HOME right) #21583

Closed Gabrielerusso closed 2 years ago

Gabrielerusso commented 3 years ago

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

Yes, and the problem still exists.

Bug Description

Marlin applies an incorrect Z offset after bed leveling, when using the simple "home" the Z axis offset is perfect, i printed like that for a month, but then i tried the auto bed leveling feature and it ruined a new PEI sticker... The print bed, after homing, it's off by 0.85mm all the times, the right Z offset, that works with home, is -1.85mm but after the auto bed leveling the bed it's 0.85mm higher than it should be, so i need to set the offset at -1mm after bed leveling and -1.85mm when bed leveling is disabled, this is a nosense. I tested it with Marlin 2.0.7.2 and also with bugfix-2.0.x, doing a quick research i found out that i wasn't the online one in those years to get the same problem, and i didn't find any solution.

Bug Timeline

From a google research this is a bug or problem present since 2016, at least other people had the same issue in the past

Expected behavior

I expected to get a leveled bed and good adesion, not a nozzle scratching the PEI bed, actually if i put the nozzle at the right height it works pretty well

Actual behavior

nozzle scratching the PEI bed, as it's 0.85mm lower than it should be

Steps to Reproduce

-Home Z -Move Z to 0 -put a paper between nozzle and bed to check homing, and it's perfect -Auto bed leveling -Move Z to 0.8 and the nozzle it's already touching the bed -Move Z to 0 and the nozzle it's pushing the bed down of around 0.8mm

Version of Marlin Firmware

bugfix-2.0.x

Printer model

custom prusa bear like frame

Electronics

mks sgenL V2

Add-ons

TriangleLab 3D-Touch

Your Slicer

Prusa Slicer

Host Software

Repetier Host

thisiskeithb commented 3 years ago

Please attach your configs.

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

Gabrielerusso commented 3 years ago

i was doing all sort of test with different configurations to provide you more information possible when i noticed there was "#define Z_MIN_POS -1" still configured from the previous configuration. I replaced this value with something like -10 just to have a pretty clear visual reference and the problem was this! Setting Z_MIN_POS to 0 and setting the z_probe_offset from -1.85 to 0.85 solved all sort of problems and the results where consistend between homing and auto bed leveling. Z_MIN_POS was not affecting the 3d printer when Homing, but was being used after auto bed leveling. If i'm right this is not documented anywhere and to me looks like an unwanted feature. I don't actually have the time to look into the code itself, but if you understood what happened or if you wan't some specific informations please tell me and i will try to give them.

Otherwise if this is just and "user error", and partially it is, then close this, but as i've seen other of this issues in the past year, without an explanation, i think this could be it.

Please attach your configs.

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

  • 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.
  • Send M502 and M500 to ensure your Configurations are applied.
  • 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.
  • Do some of the moves that revealed problems before. Take notes.
  • Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

wwoody007 commented 3 years ago

I have exactly the same problem, which I could observe several times yesterday, after upgrading the firmware 2 days ago. In my configuration Z_MIN_POS is 0 (default) and after PROBE WIZZARD (bltouch z offset measured with caliper exactly -2.88) and BED LEVELING, I have to increase the height of the Z axis by exactly 1 mm to -1.88 mm, otherwise the nozzle drills into the bed. I am fairly new to 3D printing but the error is repetitive and reproducible.

edit: Sorry, I forgot .. I am using the Ender 3 Pro with MicroSwiss hotend and bltouch. Everything is neatly mounted and measured and worked fine until 2 days ago. Marlin_Config.zip

wwoody007 commented 3 years ago

Just tested. Same configuration files but Marlin-bugfix-2.0.x from March 29, 2021. EEPROM initialized, everything reset, auto Z-align performed, corners leveled, probe wizzard performed, bed leveled and it works like a dream.

Gabrielerusso commented 3 years ago

Just tested. Same configuration files but Marlin-bugfix-2.0.x from March 29, 2021. EEPROM initialized, everything reset, auto Z-align performed, corners leveled, probe wizzard performed, bed leveled and it works like a dream.

Maybe there was an offset set in EEPROM and after the re initialization it got back to default values.

wwoody007 commented 3 years ago

I initialize the EEPROM every time I flash a firmware and also do "reset to default" aka M502 and M500. Have looked everywhere in my configs to see if somehow, somewhere a 1 mm setting is set. Nope, nothing there. Right now I am printing in TPU with Marlin-bugfix-2.0.x from March 29, 2021. It works like a charm. No problems at all.

Mainboard built in: BTT SKR E3 Turbo (LPC1769)

I am still not sure about every setting I made, but it works well now. Still optimizing the config for the SKR E3 Turbo. Need to change that noisi allways running controller fan to some other pin.

JWest1969 commented 3 years ago

I have a gigabot 2.0 from RE:3D. I recently upgraded my printer to have a BTT SKR Pro V1.2 board with TMC2209 drivers, a BTT 35 E3 V3 display and a genuine BLTouch for bed probing. After running the G29 mesh probing routine used by ABL I notice the values stored seem incorrect. I know my bed is level and that there is a section that dips down and back up in one area. I expected to see this reflected in the mesh values but did not. I must use the mesh editor to touch off each point manually to get it working as expected. Before leveling manually, a test print is too close on the left side and too far away on the right. (along the X axis) I am curious as to why this is happening. I have seen several posts from people seeming to have similar problem but no solution. What I wonder is:

  1. Are the z values stored in the list accurate?
  2. If the values are accurate could the value itself being stored in the wrong index for the mesh?

I notice that when using ABL the G29 routine starts probing at index bottom right corner I0 J9 (10x10 mesh) and works its way back to I0 J0 then forward I1 J0 to I1 J9 in a zig zag pattern until it ends up at I9 J9. (Top right corner). I wonder if this is the intended pattern? I would have thought the pattern should start at I0 J0 (bottom left) and end up at I9 J9 (top right) but I have no idea the intent. Could the program loop that controls the pattern position be incorrect and is scrambling up the stored values in the wrong actual position on the bed? Any help is greatly appreciated. It takes a lot of time to probe 100 points manually and is why I got the BL touch to automate the process.

Also, I have tested both the bugfix and release versions of most recent Marlin 2.0.7.2. In both version it compiled ok for me with platformIO. However the following items were flagged as problems:

Abl.cpp narrowing conversion of '((destination.XYZEval::.XYZEval::::.XYZEval::::::x - bilinear_start.XYval::.XYval::::.XYval::::::x) * bilinear_grid_factor.XYval::.XYval::::.XYval::::::x)' from 'float' to 'short int' [-Wnarrowing]

narrowing conversion of '_MAX<short int, short int>(c1.XYval::.XYval::::.XYval::::::x, c2.XYval::.XYval::::.XYval::::::x)' from 'int' to 'signed char' [-Wnarrowing]

narrowing conversion of '_MAX<short int, short int>(c1.XYval::.XYval::::.XYval::::::y, c2.XYval::.XYval::::.XYval::::::y)' from 'int' to 'signed char' [-Wnarrowing]

tombrazier commented 2 years ago

I suspect this issue is about not setting NOZZLE_TO_PROBE_OFFSET correctly and can be closed. The OP mentions solving the problem by setting "z_probe_offset".

I would recommend anyone having the same problem look at NOZZLE_TO_PROBE_OFFSET and also enable PROBE_OFFSET_WIZARD in Configuration_adv.h which makes it easy to determine the Z value for NOZZLE_TO_PROBE_OFFSET. Just make sure you have the latest bugfix if also using probe temperature compensation - otherwise the Z value will not take temp compensation into account.

github-actions[bot] commented 2 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

github-actions[bot] commented 2 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.