Skip to content

MBL stops after homing all axes #13655

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
robbycandra wants to merge 1 commit into from
Closed

MBL stops after homing all axes #13655

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Marlin/src/lcd/menu/menu_bed_leveling.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -194,7 +194,7 @@
ui.defer_status_screen();
set_all_unhomed();
ui.goto_screen(_lcd_level_bed_homing);
enqueue_and_echo_commands_P(PSTR("G28"));
enqueue_and_echo_commands_P(PSTR("G28\nG29"));
Copy link
Member

@thinkyhead thinkyhead Apr 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extra G29 here is interesting, because for MBL it just prints the current state. So I suspect that almost any G-code would kick things off here. Since this is a hack and will definitely cause problems with ABL+PROBE_MANUALLY, I would prefer to find the actual cause why the procedure gets "stuck" for some people and do a proper fix of that instead.

Note that so far I have not been able to reproduce the problem this is intended to fix. I am able to do a full 36-point leveling without issue using ABL_BILINEAR+PROBE_MANUALLY. I have tested MBL in the past and I will give it another test shortly. I'm using a graphical display in most of my testing. I've tested several bed leveling procedures in a row and they seem to work ok in my setup.

A possible cause of the "stuck procedure" issue is that the screen handler within _lcd_level_bed_homing may not be getting repeated calls, so that _lcd_level_bed_homing_done is never subsequently called (until a click or wheel even transpires). Or, the screen that says "Click to Continue" is not being drawn correctly, so it is not evident that a click is needed to go forward. Whatever the actual problem is, I will try to track it down.

Copy link
Contributor Author

@robbycandra robbycandra Apr 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah... I make mistake this time... I am not carefull enough. Yes you are correct.

Copy link
Contributor

@orcinus orcinus May 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try using MESH_BED_LEVELING instead of ABL_BILINEAR+PROBE_MANUALLY.

Copy link
Contributor

@orcinus orcinus May 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and it doesn't seem like it's a screen drawing issue, at least not with the Step 4 screen.
In fact, the first screen, the one that's supposed to display the homing message, does not get drawn at all, or, rather, you get dumped straight back to the status screen, as soon as you select the menu item.

I thought it might be an issue with defer_status_screen() and messed around with it, but no luck.

}

#endif // PROBE_MANUALLY || MESH_BED_LEVELING
Expand Down