MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.16k stars 19.21k forks source link

[BUG] Printing Head crashes after bed leveling and M500 - M501 when using Auto Bed Leveling Bilinear #26876

Closed Bergerac56 closed 2 months ago

Bergerac56 commented 6 months ago

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

Yes, and the problem still exists.

Bug Description

In certain circonstances, the printing head crashes after a Bed Leveling followed by a Store Settings and a Load Settings. (M500 - M501) It seems that the storage of the mesh is corrupting the Z behavior at some point. At least the Z value, showed on the info screen, is modified and replaced by other caracters (see attached picture). After this occured, there is a high risk that a crash will follow. Some times, I also experienced, in place of a crash, a full reset of the printer when I tried to move the Z axe.

After the storage of a mesh, even after power off the printer, a Load Settings will "contaminate" the Z value.

I checked with 2 different printers. A Wanhao/Balco printer fully modified to use plain vanilla marlin, a BLtouch and get rid of the touchscreen and a Hephestos 2 with BLTouch. I got exactly the same result.

Why did I not notice this before? Because I normally do not store the mesh but perform a "fresh" G29 for each print through gcode added to the print files. This means that, usually, there are no meshes in my EEPROMs

See "steps to reproduce" for more infos.

Bug Timeline

At least 6 months ago. I experienced some crashes in the past but started only to investigate this 2 weeks ago.

Expected behavior

Being able to store a "bilinear" mesh in EEPROM without creating a situation where the head could crash. Expecting no corruption of Z value after a LOAD SETTINGS

Actual behavior

Storage of a mesh and reloading Settings seems to affect Z movements. This could lead to crashes

Steps to Reproduce

  1. Initialize EEPROM
  2. G29 (Auto Bed Leveling Bilinear is the firmware option chosen in config file. Z probe is BLTouch)
  3. After completion of G29, the printing head is waiting on the last position of the bed leveling cycle. (Be sure Bed Leveling is On at this stage)
  4. Do a Store Settings followed by a Load Settings
  5. Come back to info screen : Z position is replaced by Z- *.,( Always the same combination of caracters. See joined picture
  6. Perform a HOME or try to do a Move Z . Most of the time, the head will crash (hardly and quickly. I broke the printer the first time).
  7. After this sequence, each time one will reload settings (M501), Z value will be corrupted on the info screen and condition for a crash will exist.

Version of Marlin Firmware

Bugfix 2.1.x 9a1c993 distribution date 2024-03-10

Printer model

Hephestos 2 with BLtouch and Marlin firmware / Wanhao printer fully modified to fit with marlin and BLtouch (no touchscreen)

Electronics

Stock electronic,

LCD/Controller

Hephestos: Original LCD / Wanhao: REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Other add-ons

BLTouch for the 2 different printers

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

None

Don't forget to include

Additional information & file uploads

Config files.zip Info screen

ellensp commented 6 months ago

You need to provide sufficient files to build your firmware... You have made changes to get the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER to work.

Please provide changed files.

Bergerac56 commented 6 months ago

You are right. I forgot the modified "pin" file (to replace original file in ramps folder). Sorry for that

Config files.zip

vfbank commented 6 months ago

/Marlin/src/inc/Conditionals_post.h b/Marlin/src/inc/Conditionals_post.h Original => #if ALL(ENDSTOPPULLUPS, USE_Z_MIN_PROBE) Replace => #if ALL(ENDSTOPPULLUPS, HAS_Z_MIN_PROBE_PIN)

Edit it like this and compile it

Bergerac56 commented 6 months ago

@vfbank Thank you. I edited the file as suggested, compiled it, followed the steps to reproduce and... chashed the printer head immediately.

This adaptation did not help for me. The Z value is still corrupted on the info screen as decribed above and a move of Z at this point induces a move of X, Y and Z together till it crashes. BTW I do not see the potential impact of endstoppullups on the storage of a mesh and the corruption of the info screen. So it has to come from somewhere else ;-)

ellensp commented 6 months ago

@vfbank that patch is for a bug in 2.1.2.2... when probe port pullup is not enabled, doesn't have anything to do with this issue. where probe is plugged into z-min port and wrong version of marlin.

Bergerac56 commented 6 months ago

Digging further, it seems to happen only with AUTO_BED_LEVELING_BILINEAR. I checked with AUTO_BED_LEVELING_LINEAR and was unable to reproduce the issue.

AUTO_BED_LEVELING_BILINEAR has an option: #define EXTRAPOLATE_BEYOND_GRID (activated in my version of configuration.h. Disabling it seems to solve the issue. I guess the issue is related to this option. Moreover, this option is not available with AUTO_BED_LEVELING_LINEAR, witch could explain the fact that the "Linear' option is not affected.

github-actions[bot] commented 3 months ago

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.

github-actions[bot] commented 2 weeks ago

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.