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.27k stars 19.23k forks source link

[BUG] Auto Bed Leveling is permanently Disabled! #23341

Closed Vysper7 closed 2 years ago

Vysper7 commented 2 years ago

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

Yes, and the problem still exists.

Bug Description

Auto bed leveling doesn't work. Using the M501 command to reveal its status always results in 'off' but when using M420 after M420 S1 makes it say 'on', yet it definitely isn't as my prints are coming out s***. Enable_ABL after G28 is configured in marlin but it doesn't help. Also I've tried everything and nothing works. The BLTouch definitely does though and so does the firmware & printer. It just won't let auto_bed_leveling stay 'on'. Is there any way to hardcode the auto_bed_leveling status as 'on' into the eeprom through the firmware bcs rn its hardcoded as 'off', like have it set to 'on' in the firmware when flashing. Please help I beg you.

Bug Timeline

N/A

Expected behavior

I expected the printer to compensate for slopes by enabling automatic bed leveling.

Actual behavior

It didn't bloody ride the contours of the bed!

Steps to Reproduce

Look I'm unsure about this one but I guess:

  1. Be an innocent man and just download Marin and use the example ender 3 configuration
  2. Make sure to enable auto bed leveling in configurations.h
  3. Use auto build marlin and flash the firmware
  4. Have the stupid printer not use its auto bed leveling to compensate for slopes.

Version of Marlin Firmware

bugfix-2.0.x

Printer model

Ender 3 Pro

Electronics

Creality V4.2.7 Mainboard

Add-ons

BLTouch

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Additional information & file uploads

Config Files.zip

Start Gcode: ```gcode M117 Super Slicer S.Gcode G90 ; use absolute coordinates M83 ; extruder relative mode M104 S120 ; set temporary nozzle temp to prevent oozing during homing and auto bed leveling M140 S[first_layer_bed_temperature] ; set final bed temp G4 S10 ; allow partial nozzle warmup G28 ; home all axis G29 ; ABL M420 S ; Restore Bed Mesh from Leveling G1 Z50 F240 G1 X2 Y10 F3000 M104 S{first_layer_temperature[initial_extruder]+extruder_temperature_offset[initial_extruder]} ; set final nozzle temp M190 S[first_layer_bed_temperature] ; wait for bed temp to stabilize M109 S{first_layer_temperature[initial_extruder]+extruder_temperature_offset[initial_extruder]} ; wait for nozzle temp to stabilize M117 Purging extruder SS G1 Z0.4 F240 G92 E0 G1 Y140 E50 F1500 ; prime the nozzle G1 X2.3 F5000 G92 E0 G1 Y10 E50 F1200 ; prime the nozzle G92 E0 M117 By your command! SS ```
thisiskeithb commented 2 years ago

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

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

borland1 commented 2 years ago

Good suggestions. On this one...

Do some of the moves that revealed problems before. Take notes.

... From the host software, what G-code should be sent to accomplish this? Should the bed mesh data be modified with G-code to exaggerate moves at the center of the bed in order to visually see the affects of auto bed leveling being functional?

Vysper7 commented 2 years ago

The Terminal Log: Log#1.txt

I also included M420 at the end which told me that bed leveling was on & M501 which gave a confusing result. Anyway, after that I straight away printed a bed test print and made sure the bed was wonky so it would be obvious if the printer didn't compensate. And go figure, it somehow didn't compensate.

The start gcode of the print: Start Gcode.txt The start gcode includes G29 but somehow the printer doesn't compensate. I have no idea what's going on!

Picture of the print: IMG_0530 Large It might be hard to see but the print was too close on one end and too far on the other.

Screen Shot proving that the bed really is wonky: (And that the BLTouch Works)

Screen Shot 2021-12-24 at 12 31 53 PM

Please Help

thinkyhead commented 2 years ago

Everything in the log seems okay. Except at the end, of course, where M501 is re-loading settings from EEPROM, which (of necessity) disables bed leveling. But, you're probably not doing M501 all the time, just for demonstration, yes?

borland1 commented 2 years ago

Vysper7,

Try printing a file without filament loaded in your machine to observe the Z axis lead screw/motor movement on the first layer. You can edit the mesh values with M421 to exaggerate the Z axis rod movements as the nozzle moves across the bed during a print. On a 6 x 6 grid, you can send g-code:

M421 I3 J3 Z-2.00

which will set the center grid value to 2mm above, then save the change with M500 before running the print file. If the Z axis lead screw/motor are seen moving back and forth on first layer, then bed compensation is working and you likely have a lead screw backlash or bed adhesion problem.

Edit: I misread your Configuration.h file, so I have edited this message since I now see you are using a 6 x 6 grid mesh.

thinkyhead commented 2 years ago

Try printing a file without filament loaded in your machine to observe the Z axis lead screw/motor movement on the first layer.

Well, heck, you only need to open up the host console and do a G29, then look at the mesh with M420 V, and then maybe edit the mesh to make things more obvious, and then do a few G1 moves. With M114_DETAIL enabled the M114 D command will display extra information about leveling correction at the current point. With DEBUG_LEVELING_FEATURE enabled the G29 Q command (ABL only) will also display extra information about bed leveling at the current position.

github-actions[bot] commented 2 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

github-actions[bot] commented 2 years 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.