Mesh Bed Leveling - RCBugFix (24/12/2016)

[psavva]

When going to Prepare - Level Bed.
The Z lifts, and you expect it to start homing.

The LCD says (Homing XYZ), and it just stays there.
No movement, No Homing.

The revision of RCBugFix is 922c67f

[psavva]

Configuration: http://pastebin.com/V9kpnShH

[epatel]

Sorry to hear that.
When looking though the commit history (https://github.com/MarlinFirmware/Marlin/commits/RCBugFix) my first guess would be this commit d0e24e0
So maybe try to narrow down which commit that caused this new behaviour. Does that commit experience the same behaviour and the commit before that 2dbd38c does not it is a clue where a bug got introduced.
Another method to find a bug that got introduced is to do a binary search, i.e. go back say about 120 commits and see if the bug is there. If its not, select the commit 60 steps back and then in a binary search way narrow down to the commit that introduced the bug. 7 tests should be sufficient to find a commit in about 120 commits (7 bits -> 128).
Good luck and Merry Christmas! :)

[brainscan]

Does mesh levelling work with a bltouch?

[manianac]

@brainscan, Mesh leveling is meant for when you don't have a sensor, and you adjust each point manually (checking nozzle height).

If you have a sensor such as a BLTouch, use auto bed leveling instead. Bilinear leveling is what you're looking for to get the same results as mesh bed leveling.

[edit] I see now @psavva has BLTouch defined in his configuration, missed that before.

[psavva]

@maniac,
Actually, mesh bed leveling is supposed to compensate for an uneven bed on multiple planes.

My bed is 400x380, and I'm using normal 6mm glass sheet, not borosilicate. (Extremely expensive in my country)

So attempt 1 for me is to use a not so perfect glass window, which costs 5 EUR.

The BLTouch is used to probe the z height. It was working before on RC 8, but with a different bug...

[manianac]

Yes @psavva, but Bilinear auto bed leveling can do the same thing using your BLTouch. Mesh bed leveling is just doing the process manually. Read the configuration notes to see the differences.

@psavva I would recommend you use auto bed leveling with your BLTouch, but if you still choose to use mesh bed leveling, then enable DEBUG_LEVELING_FEATURE in Configuration.h, and issue a `M111 S35 to output debugging over the serial connection. You will need to hook your machine up to a computer of course.

[brainscan]

Yeah I've been using it since it was first added I know how it works. I was asking if things had changed and if it could be used with a probe now as I thought that was in Roxy's UBL but not in RCBUGFIX yet.

[psavva]

They is great, I'll enable Bilinear Bed Leveling then.
However, still need to find the issue so we can fix it.

I'll have to test it after Christmas and see if I can find the root cause.

[manianac]

Sounds good. Enable debugging to help that process.

[Fixx]

I experience the same issue with RCBugfix dated 15/12/2016.

[ghost]

Same issue here today. I'm not sure why it's waiting or what it's waiting for, yet.

[ghost]

This is not an issue? Looks like it will just wait forever.

while (!axis_homed[X_AXIS] || !axis_homed[Y_AXIS] || !axis_homed[Z_AXIS]) idle();

[ghost]

If I do this:

inline void lcd_wait_for_homing() {
no_reentrance = true;
while (!axis_homed[X_AXIS] || !axis_homed[Y_AXIS] || !axis_homed[Z_AXIS]); // idle();
no_reentrance = true;
}

It doesn't wait forever....but Marlin resets 5 secs or so after raising z. Although, nothing homes..

[ghost]

In this function:

void _lcd_level_bed_continue() {
  defer_return_to_status = true;
  axis_homed[X_AXIS] = axis_homed[Y_AXIS] = axis_homed[Z_AXIS] = false;
  mbl.reset();
  enqueue_and_echo_commands_P(PSTR("G28"));
  lcd_goto_screen(_lcd_level_bed_homing);
}

The serial monitor shows: echo:enqueueing "G28"

[ghost]

I comment out this line:

//lcd_wait_for_homing();

Added this line from RC:
if (axis_homed[X_AXIS] && axis_homed[Y_AXIS] && axis_homed[Z_AXIS])

All in the ultralcd.cpp within the _lcd_level_bed_homing() function.
And I have bed leveling again!! WooHoo!!

[ghost]

I don't know what the REAL fix is for this is but, this fixed it for me.

[ghost]

void _lcd_level_bed_homing() {
  if (lcdDrawUpdate) lcd_implementation_drawedit(PSTR(MSG_LEVEL_BED_HOMING), NULL);
  lcdDrawUpdate =
    #if ENABLED(DOGLCD)
      LCDVIEW_CALL_REDRAW_NEXT
    #else
      LCDVIEW_CALL_NO_REDRAW
    #endif
  ;
  if (no_reentrance) return;
  //lcd_wait_for_homing();   //Let's not go there.
  if (axis_homed[X_AXIS] && axis_homed[Y_AXIS] && axis_homed[Z_AXIS])  //added from RC
  lcd_goto_screen(_lcd_level_bed_homing_done);
}

[ghost]

This is also going to be in my PR for the DHT sensor. Only because it works.

[psavva]

@thinkyhead, can you review and comment on the suggested fix?

[ghost]

I will say that the LCD responsiveness is much faster than the RC.

[Blue-Marlin]

The real fix is to home the machine before doing any moves.

[ghost]

Raising Z before homing is working. The problem was that it was not homing any axis. It would raise Z and stop.

[ghost]

I do have this issue now..

  if (axis_homed[X_AXIS] && axis_homed[Y_AXIS] && axis_homed[Z_AXIS])
  lcd_goto_screen(_lcd_level_bed_homing_done);

This doesn't always update the lcd until I move the encoder or click the button.

Sometimes it works just fine, other times the LCD still shows "Homing XYZ" after homing is complete.

[manianac]

I'd say the real fix is looking into lcd_wait_for_homing and determine why it's not working

…

On Dec 27, 2016 3:28 PM, "Tannoo" ***@***.***> wrote: I do have this issue now.. if (axis_homed[X_AXIS] && axis_homed[Y_AXIS] && axis_homed[Z_AXIS]) lcd_goto_screen(_lcd_level_bed_homing_done); This doesn't update the lcd until I move the encoder or click the button. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5592 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB_uHT6L_1i5-s9CZTr2UcS7KIDPLqtmks5rMXTtgaJpZM4LVN29> .

[epatel]

Interesting findings. Sry I can't test myself. Well, according to the commit history the lines you have changed recently was introduced into this commit b4dbf4d
So, a test to do would to try the commit just before that, this commit 7b625e0

[ghost]

@manianac

I'd say the real fix is looking into lcd_wait_for_homing and determine why
it's not working

Well, here's the function:

inline void lcd_wait_for_homing() {
no_reentrance = true;
while (!axis_homed[X_AXIS] || !axis_homed[Y_AXIS] || !axis_homed[Z_AXIS]) idle();
no_reentrance = true;
}

I only see it sitting forever doing nothing (idle()) while any of the axis are not homed (!axis_homed).

When I comment out the idle() command, Z moves up for the clearance and the system restarts, every time.
When I comment out the first no_reentrance = true;, Z moves just enough to make a noise, then the system restarts, every time.
When I comment out the second no_reentrance = true;, the system doesn't restart, but when I select the Level Bed on the confirmation screen... nothing happens.

BTW, I get this same 'hang-up' if I put while (!axis_homed[X_AXIS] || !axis_homed[Y_AXIS] || !axis_homed[Z_AXIS]) idle(); instead of if (axis_homed[X_AXIS] && axis_homed[Y_AXIS] && axis_homed[Z_AXIS]) in the void _lcd_level_bed_homing() function.

So, I dunno. Maybe that while needs to be an if. I haven't tried that. The if wouldn't be stuck in it's own loop.

[ghost]

Ok, I just tried that. Everything works with that upto the 1st point of measure. Then I can't do anything. Screen says, Move Z: 0.000. I can't move Z, and clicking the encoder does nothing. Now, it's hung up in a different spot.

Also, the screen changed to click to begin as soon as the homing process begun instead of waiting for the homing to finish.

[ghost]

I put in a PR. (#5634)

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