[BUG] LCD-Bedleveling doesn't work

[schuessm]

Description

I configured LCD-Bedleveling (manual leveling). I've got an entry on my LCD display to do the leveling. But when I use it, the printer homes all axes an leave the menu. That problem is only with 2.0.x, with the version 1.1.9 it works.
I use the version from 5th of April 2019

Config.zip

[reloxx13]

link #13181
could be same issue.

[Classictinker]

I also have to same issue with 2.0.x has this been sorted out yet or is it still a mystery???

[LyaminSS]

I also have this problem.

menu_bed_corners - works.
menu_bed_leveling - does not work

In both cases, it does not appear: Display "Homing XYZ" - Wait for homing to finish

bugfix-2.0.x/Marlin/src/lcd/menu/menu_bed_leveling.cpp - I edited this file to go directly to step 4 -then bed level works

// Step 4: Display "Click to Begin", wait for click
// Move to the first probe position

This is a bad decision.
Please fix it.

[LyaminSS]

enqueue_and_echo_commands_P ( PSTR ( " G28 " ));
enqueue_and_echo_commands_P ( PSTR ( " G28 \ n G29 " )); - did not help

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

[LyaminSS]

No, the problem is not solved.

[boelle]

can you help fix it?

[LyaminSS]

Maybe. How can I help?

[boelle]

figure a fix and submit a PR

[LyaminSS]

I'll try.
The problem is that I don’t know how to debug the code. And I have to compile the firmware, upload it to the board. And test. Takes a lot of time.

[boelle]

i dont do code at all, i just help the project by closing issues that go dead so to speak
and of course reopen if the issue is not solved, a kind of janitor if you like.

and the more help the project can get the better as those that do write code only have so many hours they can spend and they only have 2 hands for the keyboard

[rwmech]

I also have the same issue. I will take a look at the code since I was able to find this and see if I can submit a fix.

[Roxy-3D]

@schuessm You have the original mesh bed leveling active. It was a break through when that first showed up. But it is only kept around because it is very small and for its historical value.

You should enable either UBL or Bi-Linear.

I suspect you will be happy with either of those.

[rwmech]

@Roxy-3D indeed much happier with AUTO_BED_LEVELING_UBL but what is not clear is that option works with PROBE_MANUALLY. Reading the description in configuration.h it would seem that the only option truly available for manual probing is MED_BESH_LEVELING.

I'm going to submit a PR to update the comments in configuration.h. While a pretty low priority PR if I was confused by those comments (and apparently @schuessm as well) I imagine others coming from 1.1.x are going to have the same issue. If MESH_BED_LEVELING has no value it would be good to remove it instead of keeping it for historical value. :)

Thanks again @Roxy-3D.

[boelle]

@schuessm still having issues?

[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]

Sorry I haven't checked in on this sooner. I'll poke around and see what the likely cause is. If I need more information I'll follow up with questions.

[Vladimir-VS]

Scott,thanks for looking into that. In case this is not clear -- this is the same issue as the one open as #16614 and handled by Bo.  edit: removed email headers

[boelle]

i closed the other one as you said this and #16614 are the same issue and we only need one open for the same issue. Else we would end up with 5 or more with the same issue

[Vladimir-VS]

retested retest with bugfix 2.0.x from here https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x
the issue is still there.

[sjasonsmith]

I was looking at issue #16458 tonight, without realizing it was a duplicate of this. I didn't see the comment that @thinkyhead would look at this, but I'm assuming he was busy with other things and hasn't had a chance yet. If I am wrong, let me know and I can step aside!

I found the source of the problem. These configurations all have two extruders (which is why it doesn't happen for everybody!). The homing operation performed before the leveling procedure performs a tool change, and the tool_change function explicitly returns to the status menu.

I've hacked the code to prevent this, and confirmed that this is the cause. I can now proceed with the leveling procedure. I need a little more time to decide on a cleaner way to solve the problem, but I expect to post a pull request to fix it in the next day or two.

[afaulkner420]

AHH brilliant! Is there any chance of a sneaky workaround with what you have done to get this working untill you figure out the cleaner code?
I miss MBL on the LCD. It's so much more convenient than through a computer!

[sjasonsmith]

Is there any chance of a sneaky workaround with what you have done to get this working untill you figure out the cleaner code?

You can try this, but it is entirely possible it will break something elsewhere. If it does, you would notice because your printer would not return to a status screen when you expect it it. This is why I need to examine the code closer to see what side-effects any change is likely to cause.

Replace this function in menu.cpp:
void MarlinUI::return_to_status() { if (!ui.defer_return_to_status) goto_screen(status_screen); }

This will currently not work if you have LCD_TIMEOUT_TO_STATUS explicitly set to false in Configuration_adv.h, but that is probably uncommon. Commented out is fine, because it uses a default value in that case.

[afaulkner420]

Ah that works perfectly for now! obviously ill let you know if i encounter any problems or anything...
Thank you!

[sjasonsmith]

@afaulkner420 I ended up posting a less risky change in my pull request. It is equally simple, but avoids the risk of breaking other behavior not related to bed leveling or tool changes.

Perhaps you could test out that change as well, and post to the PR whether it fixes the issue for you?

#16688

[thinkyhead]

Thanks for the follow-up. I've kept this tab open, but I got pulled into tasks related to the 2.0.2 release. The 2.0.3 update is planned to be a smaller followup, so this fix will be out there soon.

[sjasonsmith]

@afaulkner420 can you verify that the fix as it was submitted to 2.0.3 works for you? I don't think @schuessm is still paying attention to this issue, so if you can confirm it is good then this issue can be closed.

[afaulkner420]

@sjasonsmith sorry, I've been busy with work this week. I'll be testing this tonight or tomorrow. I shall jump back on here the second I've tested!

[boelle]

@afaulkner420 did you get time to restest?

[afaulkner420]

Haha apparently I commented on the wrong one! Yes I did! And it works perfectly! Now I just have to get the settings boned down for a very temptemental dual extruder! Haha;

[boelle]

@schuessm are you still with us?

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