[BUG] Enabling Linear Auto Bed Levelling breaks Y and Z axes

[hasmar04]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

When using the bugfix branch on an Ender 5 with the v4.2.7 mainboard and a BLTouch, the G29 command executes successfully, but once complete changes the Z position to high above the bed but also breaks the Y axis, which during prints means only the X and E axes respond to commands, leading to lines being drawn in mid air along the Y coordinate where G29 completes.
The BLTouch works as expected during G28 and does use the Z Probe Offset configured in the firmware.
Also, if the mesh from G29 is saved to EEPROM and reactivated later, it has the same effect and breaks the axes.

By switching back to the stable branch and using the same configuration, the problem does not exist and G29 works as expected.

Bug Timeline

May be old bug, just recently installed Marlin on the printer.

Expected behavior

G29 command is executed, followed with the printer using that data to print on the tilted bed.

Actual behavior

G29 executes correctly until at the end where it raises the Z, then stops the Y and Z axis responding, while the coordinates they should be at are displayed on the LCD.
Applying the saved mesh also has the same stepper freezing effect.

Steps to Reproduce

1. Download bugfix branch and the default 427 Creality configuration for the Ender 5
2. Enable BLTouch and AUTO_BED_LEVELLING_LINEAR as well as Z_SAFE_HOMING (Configuration attached)
3. Compile using PlatformIO
4. Flash and connect to printer (used Octoprint)
5. Send G28, confirm all axes still work
6. Send G29, confirm X works, like Y, Z do not

Version of Marlin Firmware

Marlin bugfix-2.0.x (Jun 12 2021 11:00:46)

Printer model

Ender 5

Electronics

Mainboard v4.2.7

Add-ons

BLtouch as Z Stop

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Configration.zip

[DerAndere1]

I heared of a similar report but in that case all axes were blocked by G29 with AUTO_BED_LEVELING_3POINT: DerAndere1#44 (comment)

[DerAndere1]

This is certainly caused by commits related to 6axis support (e.g. #21953 or #19112).

I have no experience with bed leveling and no means for testing it in hardware, so help from another dev is needed.

[DerAndere1]

@hasmar04 : Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

1. Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
2. Connect to your printer from host software such as Cura, Printrun or Repetier Host.
3. Send M502 and M500 to ensure your Configurations are applied.
4. Issue the command M111 S247 to enable maximum logging.
5. Perform a G28 to do your standard homing procedure.
6. Do a G29 to probe the bed. This will also enable bed leveling.
7. Do some of the moves that revealed problems before. Take notes.
8. Copy the log output into a .TXT file and attach it to your next reply.

[hasmar04]

I followed your steps above and have attached a log below.
I used the same settings as before but I downloaded the latest version of bugfix-2.0.x and applied my changes to the latest example configurations for the Ender 5.
Also of note is the logs did not include anything that I could see to show that when G1 commands were issued, the X moved while the Y and Z stayed stationary with the LCD location for those axes updated to what I entered.
debug_output.log

[EzeKoren]

This is certainly caused by commits related to 6axis support (e.g. #21953 or #19112).

I have no experience with bed leveling and no means for testing it in hardware, so help from another dev is needed.

I can confirm this bug is not present on Marlin 2.0.8, which means that's what's most likely causing the problem.

Until this is fixed @hasmar04 I suggest you roll back to Marlin version 2.0.8. you won't be missing out on many features, for the release 2.0.9 is mostly centered around the introduction of a new motion system which, unless you have a very custom printer with more or less than 3 axis, you can't take advantage of.

Hope this helps you get your printer back up and running

Happy printing!

[hasmar04]

That's what I did already to identify the problem. Good luck to all in rectifying this.

…

On Mon, Jul 12, 2021 at 11:19 AM Ezequiel Korenblum < ***@***.***> wrote: This is certainly caused by commits related to 6axis support (e.g. #21953 <#21953> or #19112 <#19112>). I have no experience with bed leveling and no means for testing it in hardware, so help from another dev is needed. I can confirm this bug is not present on Marlin 2.0.8, which means that's what's most likely causing the problem. Until this is fixed @hasmar04 <https://github.com/hasmar04> I suggest you roll back to Marlin version 2.0.8. you won't be missing out on many features, for the release 2.0.9 is mostly centered around the introduction of a new motion system which, unless you have a very custom printer with more or less than 3 axis, you can't take advantage of. Hope this helps you get your printer back up and running Happy printing! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AII6EEBGLBGUDNPKWGDVMLLTXI7ILANCNFSM46TH4KFA> .

[MiNdLiKeAsPoOn]

I fixed the problem by changing the type of bed levelling to UBL. Hopefully that should save you some time instead of rolling back the firmware version

[EzeKoren]

I fixed the problem by changing the type of bed levelling to UBL.

Sadly UBL doesn't work for my use case, as I have a glass flat bed, and the mesh is taken from the uneven metallic heated bed that sits below it. For all the folks who cannot use UBL, seems like the only solution is to downgrade. Hope this gets fixed quick

[DerAndere1]

I fixed the problem by changing the type of bed levelling to UBL. Hopefully that should save you some time instead of rolling back the firmware version

This is very helpful information. so I expect that the buggy code is not somewhere in the Marlin core but rather in (non-UBL) bed-leveling code in motion.h/motion.cpp or in feature/bedlevel/. Someone who knows basics in C++ and who can test bed leveling could replace mentioned files one by one with the respective files from Marlin just before my 6 axis support was merged (https://github.com/MarlinFirmware/Marlin/tree/733d5fd57d6343fcd8643d322129845b57945cad) and report when the bed leveling bug disappears.

[thebestnom]

@hasmar04 : Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

1. Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
2. Connect to your printer from host software such as Cura, Printrun or Repetier Host.
3. Send M502 and M500 to ensure your Configurations are applied.
4. Issue the command M111 S247 to enable maximum logging.
5. Perform a G28 to do your standard homing procedure.
6. Do a G29 to probe the bed. This will also enable bed leveling.
7. Do some of the moves that revealed problems before. Take notes.
8. Copy the log output into a .TXT file and attach it to your next reply.

I suggest adding this to the bug report template

[thebestnom]

I fixed the problem by changing the type of bed levelling to UBL. Hopefully that should save you some time instead of rolling back the firmware version

This is very helpful information. so I expect that the buggy code is not somewhere in the Marlin core but rather in (non-UBL) bed-leveling code in motion.h/motion.cpp or in feature/bedlevel/. Someone who knows basics in C++ and who can test bed leveling could replace mentioned files one by one with the respective files from Marlin just before my 6 axis support was merged (https://github.com/MarlinFirmware/Marlin/tree/733d5fd57d6343fcd8643d322129845b57945cad) and report when the bed leveling bug disappears.

Ill try to look at that sometime this week