AUTO_BED_LEVELING_BILINEAR looping

[autonumous]

Been using Bed levelling Mode: AUTO_BED_LEVELING_BILINEAR since it was introduced in RCBugFix Branch, Just recently stopped working correctly, just continuously runs.

After power up, if i select “Level Bed” an auto homes(i.e. a G28), then it stops . Previously it would have performed a home (G28), then bed level (G29) as it shovel as per code the level bed code in ultralcd.cpp.

If i press level bed again, it proceeds to run the bed level, once it completes, my custom scrip run (Z_PROBE_END_SCRIPT) which parks the head in the dock. Then it proceeds to repeat the entire process, again and again, requiring a hard reset.

I’ve tried other bed levelling modes, e.g. MESH_BED_LEVELING, and works perfectly.

it seems something introduced into the RCBugFix branch over the last day or two has caused it.

[Bob-the-Kuhn]

Marlin is going through a rough time getting the bugs ironed out of the Unified Bed Leveling (UBL) code that was introduced this week. That code affects the LCD.

My suggestion is to go back to your old release and wait another week before trying to update.

The UBL team will see your post so I expect that a fix will be in place in the next few days.

[Roxy-3D]

Been using Bed levelling Mode: AUTO_BED_LEVELING_BILINEAR since it was introduced in RCBugFix Branch, Just recently stopped working correctly, just continuously runs.

The UBL team will see your post so I expect that a fix will be in place in the next few days.

If he had been running UBL... I think it would be working for him. I was very very careful when I hooked the UBL code into the main code body to make sure if UBL wasn't selected... None of the code paths changed. If he is having a problem with Bi-Linear leveling... My guess is it wasn't caused by UBL being merged. (Yes, I know I sound 'defensive'. )

@autonumous If you want to enable the #define AUTO_BED_LEVELING_UBL option... I'll help you bring it up. And I'm pretty sure you will be happy with it. I'm stress testing it right now with a 15 x 15 mesh on a gMax 1.5+ with 400mm x 400mm bed.

[autonumous]

Thanks @Roxy-3D I’m trying to determine if it’s something else, something i’ve introduced, or a failed merge. Will also be trying the the UBL code this week, so will let you know how that goes FYI Great work with it all guys.

[autonumous]

I’ve tried using a vanilla RCBugFix build with my existing config files, (i.e. stripped any of my custom code, and removed any possibility of any merge issues) get the same issue.
After powering on, Level Bed will perform an auto-home (G 28), then stop, subsequent selections (G 29) it will continuously run the level procedure.
Although I'll no doubt use UBL, I'd like to know why this is not working. Anybody else experience similar?

[Roxy-3D]

@autonumous You can -NOT- use your existing configuration.h files. As part of the clean up of the code base, some options have been renamed and some are split apart into multiple options to be more granular.

You really should fire up NotePad++ and enable the visual diff comparison plug in. You will be able to see where things are different and make intelligent choices about how to map your old values over to the new file.

[autonumous]

@Roxy-3D When say my existing Config, i mean config files from previous RCBugFix builds of a few days prior. Additionally I compile from my a fork, where i merge RCBugFix branches into my own dev branch, and thus review any differences between config files, making suitable updates etc.

Anyway, given that nobody else seems to have experienced similar issue, i’m not opposed to it being something in my code base or something i’ve done. just can’t determine what. But it’s odd, as i can take a vanilla RCbugFix branch, make minimal changes to it for my machine, select “AUTO_BED_LEVELING_BILINEAR” as the bed levelling method. Compile and then experience the issue. I did notice last night that if i removed the custom Z_PROBE_END_SCRIPT and then enabled DEBUG_LEVELING_FEATURE, this ‘looping’ behaviour stopped, however selecting “level” through the LCD menu, only performs an AutoHome (G28), not a G28/nG29 as per the code.

Investigation continues.....

[autonumous]

odd, noticed last night that after powering up and then selecting “Level Bed” from the LCD menu, which should perform “G28\nG29”, i see the following on the console.

Recv: ok
Send: M115
Recv: FIRMWARE_NAME:Marlin 1.1.0-RCBugFix (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:2 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: ok
[...]     **<It WAS HERE WHEN I SELECTED LEVEL BED>**
Recv: echo:enqueueing "G28"
Recv: echo:enqueueing "G29"
Recv: echo:Home XYZ first
Recv: echo:Active Extruder: 0

The message "Home XYZ first” is out put from G29, and would be displayed if the bed isn’t homed. This is displayed while its going though the AutoHome process.

[autonumous]

Just tried using the latest RCBugFix, merged with my own config and custom code. Seems to be working correctly .

i noticed the following update (https://github.com/MarlinFirmware/Marlin/commit/1a775cecac6ab9d3b1ac070a228dd2cf3c444d02), which i suspect is possibly related to the above issue, and possible other odd screwy behaviour i’ve had, or if not this, one of the many other that have been applied recently.
(my investigation was certainly showing the issue started around the time 48c6284 was implemented)

Anyway seems ok now.

[github-actions[bot]]

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.