[BUG] [Bugfix 2.0.x] Manual bed levelling stops after homing all axes

[Santobert]

Description

I followed this documentation to enable manual bed leveling:
http://marlinfw.org/docs/gcode/G029-mbl.html

After selecting Motion -> Level Bed -> Level Bed the printer homes all axes and goes back to the info screen. The status line says <My printer name> ready. Pressing the button leads to the main menu.

Steps to Reproduce

1. Enable the following options:

#define MESH_BED_LEVELING
#define LCD_BED_LEVELING

2. Select Motion -> Level Bed -> Level Bed

Expected behavior:* [What you expect to happen]
The printer homes all axes, and then "Click to Begin" appears and you can move the print head to manual leveling.

Actual Behavior:*[What actually happens]
The printer homes all axes and returns to the info screen without changes or messages.

Additional Information

Using the latest bugfix-2.0.x

[reloxx13]

i think u missed this one

/**
 * The "Manual Probe" provides a means to do "Auto" Bed Leveling without a probe.
 * Use G29 repeatedly, adjusting the Z height at each point with movement commands
 * or (with LCD_BED_LEVELING) the LCD controller.
 */
//#define PROBE_MANUALLY

[reloxx13]

u enabled the mesh and lcd level, but did not choose a probe

no probe = no leveling possible => done

[Santobert]

I tried PROBE_MANUALLY as well. The printer still shows the same behavior.

Also the documentation (http://marlinfw.org/docs/gcode/G029-mbl.html) says:

Notes
Requires the MESH_BED_LEVELING option in Configuration.h.
Similar to AUTO_BED_LEVELING_BILINEAR with PROBE_MANUALLY but uses less SRAM.

Therefore I assume that PROBE_MANUALLY does not have be activated.

[boelle]

still having issues?

[Santobert]

Yes

[reloxx13]

try a M502 followed by M500 and M501 to reset to firmware to defaults config.
maybe sth is messed up.

write down any changed params like m851 z-offset cuz they will reset to configuration.h defaults.

[thinkyhead]

Therefore I assume that PROBE_MANUALLY does not have be activated.

Correct.

…the printer homes all axes and goes back to the info screen…

It's certainly possible that a regression has occurred in the MESH_BED_LEVELING handling from the LCD. It was patched up and working well a while ago and it hasn't been touched directly since then.

I will give it a test soon and see if I can reproduce your issue.

[thinkyhead]

As part of your testing, please try AUTO_BED_LEVELING_BILINEAR with PROBE_MANUALLY to see if it has a similar result. (It's essentially the same.)

[Santobert]

Both, AUTO_BED_LEVELING_BILINEAR with PROBE_MANUALLY and MESH_BED_LEVELING, resulting in the same behaviour. After homing all axes the process stops and the printer shows the main display with the message <printer name> Ready.

The output is the following:

echo:enqueueing "G28"   
echo:Active Extruder: 0  
echo:busy: processing   
echo:busy: processing   
echo:busy: processing   
echo:Active Extruder: 0    
X:215.00 Y:-15.00 Z:0.00 E:0.00 Count X:21500 Y:-1500 Z:0   

I will attach the config file to this post for you to recreate this bug:
default.zip

[Santobert]

I've seen the same behavior while leveling the corners when I haven't used Auto home before. Then the printer also homes all axes and stops, so I have to hit level corners again. After that it usually works for this case.

Sadly this method doesn't work for the bed level process.

[thinkyhead]

It is unusual. I tested MESH_BED_LEVELING on a Geeetech A20M the other day and it worked perfectly. That machine has a graphical display, if that makes any difference.

[thinkyhead]

Your attached configs are the Marlin 2.0 default configs (I compared them to confirm).

[Santobert]

This is my current configuration. Unfortunately I'm still unfamiliar with the project structure of marlin2.

Marlin.zip

[thinkyhead]

Still no clue. Here's a procedure you can follow to gather more information:

• Download Marlin bugfix-2.0.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE 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 probe of the bed as far as you can before it fails.
• Copy the log output into a .TXT file and attach it to your next reply.

From the log we might get a better idea of what's going on with your machine.

[Santobert]

This is the log file. To avoid misunderstandings, I have added some photos of how I went through the menu. I hope this helps.

files.zip

[orcinus]

Has this been fixed? There was a PR with a fix that got rejected, but with all the opening and closing of issues, i’ve got no idea what the status is anymore.

[boelle]

there was a PR merged so its needs testing

[Santobert]

https://cloud.tobhaase.de/s/ieLPKNjES9LsZX9

Unfortunately still an issue

[boelle]

@Santobert still an issue?

[boelle]

btw... do you remember to save to eeprom when manual bed level is done?

[orcinus]

btw... do you remember to save to eeprom when manual bed level is done?

What does that have to do with not being able to run MBL in the first place?

[Santobert]

@boelle was there a pr that closes this issue? Honestly I don't plan to use manual bed leveling anymore. So close this, if you want to.

Since the bed leveling never starts I haven't saved the result :/

[boelle]

@boelle was there a pr that closes this issue? Honestly I don't plan to use manual bed leveling anymore. So close this, if you want to.

Since the bed leveling never starts I haven't saved the result :/

no if it does not work it should stay open

[boelle]

hmm, one thing to try would be

do M502, then M500 this bring the eeprom to default state
then do manual bed level
then send M500 again

you need to have this one active for it to work: #define RESTORE_LEVELING_AFTER_G28

[orcinus]

This has nothing to do with the issue.

The issue is that the manual leveling procedure is broken and exits to status screen prematurely (after step 1).

[boelle]

but why is it broken? that is the million € question

[boelle]

@Santobert a ton of updates have been done since 24 sep, i assume this is stillan issue

[Santobert]

@boelle thanks for the update. I'll do some tests this evening 😊

[Santobert]

Unfortunately the same result. I've attached my current configuration as well as a git patch with all my changes to any files.

Marlin.zip

[boelle]

one fault in your config

//#define RESTORE_LEVELING_AFTER_G28

should be

#define RESTORE_LEVELING_AFTER_G28

[boelle]

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.

[Vladimir-VS]

The issue seems to still exist. I have the same behavior of my Tevo Tarantula with an optical z-min endstop.
I tend to blame it on the is_homed valued erroneously false in the menu_bed_leveling.cpp.
A root cause my be in a logic set for the endstops:
#define X_MIN_ENDSTOP_INVERTING true
#define Y_MIN_ENDSTOP_INVERTING true
#define Z_MIN_ENDSTOP_INVERTING false
but clearly do not have a solution. All other homing works fine.

[thinkyhead]

@Vladimir-VS — How is the current bugfix-2.0.x behaving? Any better?

[Vladimir-VS]

Scott,the issue is fully fixed. Thank you,Vladimir

[github-actions]

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.