[BUG] (bugfix-2.0.x) Auto Bed Leveling does not compensate for angled bed.

OC-Rookier commented 4 years ago

Bug Description

Marlin bugfix-2.0.x does not compensate for angled beds during print.

My Configurations

Config files.zip

Steps to Reproduce

Install an SKR Mini E3 V2 into an Ender 3.
Download Marlin bugfix-2.0.x and the configuration files for the SKR Mini E3 V2 from GitHub.
Open VS Code and install Platform.IO.
Copy the Mini E3 V2 files from the configuration folder into the Marlin folder of the firmware.
Use this guide to configure the firmware correctly. Also follow instructions for setting up the BL Touch.
Build the firmware, copy the firmware.bin file to a Micro SD card, put the card into the printer, and power on the printer.
After the firmware is done flashing, manually level the bed and set up the Z offset.
Start a print, and watch as one corner is thinner than the rest of the print.

Expected behavior: [What you expect to happen]

I expected that the BL Touch would raise/lower slightly depending on how level each corner of the bed was, thus resulting in an overall uniform first layer.

Actual behavior: [What actually happens]

The printer seems to ignore the mesh that was generated during the G29 command in my starting gcode, and the print is not uniform.

Additional Information

Using Octoprint, I can see that the printer is generating a mesh when G29 is ran. This also is shown in the Bed visualizerplugin.
ABL was working when I was using the Creality 1.1.5 board and Marlin 1.1.x.
I know there are other issues that complain about ABL not compensating, but they seem to close due to inactivity with no obvious solution.
A friend of mine has the SKR 1.4 Turbo and Marlin bugfix-2.0.x and is also having issues with no compensation after mesh generation.
I am new to Github (as in just made an account to make this post), so please be patient with me.

GMagician commented 4 years ago

Bed leveling is not activated by default..not sure but maybe M420 S1 is what you need

OC-Rookier commented 4 years ago

After editing my starting Gcode to look like this:

G28 G29 M420 S1

It still does not work. The Z axis is now too high and does not stick to the bed.

thinkyhead commented 4 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

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

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.

pabds commented 4 years ago

After editing my starting Gcode to look like this:

G28 G29 M420 S1

It still does not work. The Z axis is now too high and does not stick to the bed.

The Z axis being too high is a separate issue. Bed levelling defines the topographical profile of your print surface. It does not define how far the nozzle is off the bed. The easiest way to address this is to start a print and then select 'Babysteps'. As it starts printing, spin the knob anticlockwise (lowering the nozzle) until the ABS starts to adhere to the print bed. Note the negative number that you have dialled up in 'Babysteps'. Abort the print and enter that number in Configuration, 'Z-offset'. Don't forget to hit 'Save'. Print again and it should be correct. If not tweak again.

OC-Rookier commented 4 years ago

I know about setting the Z offset, as I used that feature back in 1.1.x. I think I may have just adjusted the bed and forgot to tune my offset afterwards.

Anyway, I am currently working on getting logs that show that ABL isn't working as well, or at least as easily as it did back in 1.1.x. Results are kind of a mixed bag right now, but I'll keep testing and hopefully report back with my findings in another day or two.

pabds commented 4 years ago

This probably isn't much help, but I have it working well on my Ender 3 pro (BLTOUCH 3.1, SKR mini E3 V2.0, TFT35 E3V3, current version of Marlin Bugfix 2.0.x). There seem to be numerous subtle differences in how people attempt to set this combination up. I decided to use the dedicated probe port. Method described here, second last post. https://www.reddit.com/r/ender5/comments/g3peqn/finally_got_my_ender_5_pro_to_work_with_the_skr/ The only issue I had was that I initially didn't realise that Auto Home turned off ABL. As above, I edited my Cura profile so that it now does a G28 home followed by M501 (Load all settings from EPROM) and then M420 S1 before it prints. I also forgot, on occasion, to save the mesh to EPROM after running ABL. I heat the nozzle to 170 (below ABS melt point) and the bed to 60 prior to running ABL to prevent thermal effects on the distance between the nozzle and the bed. With all that and the z-offset tuned, it definitely works well for me.

GMagician commented 4 years ago

@pabds this is from manual on web and may clarify something to you

G28 disables bed leveling. Follow with M420 S1 to turn leveling on, or use RESTORE_LEVELING_AFTER_G28 to automatically keep leveling on after G28. To save time and machine wear, save your mesh to EEPROM with M500 and in your slicer’s “Starting G-Code” replace G29 with M420 S1 to enable your last-saved mesh.

as you can see M501 seems not needed

OC-Rookier commented 4 years ago

Alright. I have the logs for quite a few tests, and inside those logs are also notes I took while observing the printer and/or the finished print. I also have pictures of each print. It should be noted that all the prints used the exact same gcode, which is also in the .zip file. Unfortunately, this file is too big to attach directly to Github (27.6MB > 10MB), so here is a Google Drive link.

https://drive.google.com/file/d/1VopCmff3qSkRDjp-pQuWLrxkMjbZFGNK/view?usp=sharing

sjasonsmith commented 4 years ago

When you are printing can you see the Z screw turning as the print moves across the bed? This verifies that some correction is at least being attempted.

How old is the bugfix code that you are using? I made a change about two weeks ago which improved an issue which could cause inaccurate BLTouch probing. That might not be related to your problems, but it would be worth testing with the just-released 2.0.6 if you weren't already using very recent bugfix-2.0.x.

OC-Rookier commented 4 years ago

I was able to see the Z screw turning when I started a print. My version of bugfix-2.0.x is only about three or four days old.

Though I do want to bring up a point I discovered in the logs, which is that ABL is working, but the mesh it is using is not the one generated before each print. Instead, it uses the a mesh that was stored in the EEPROM, and discards the new mesh.

I do make notes inside each of the log files, as indicated by two forward slashes (//). These notes describe the print or any variables that I have changed.

minosg commented 4 years ago

I can confirm something is off.

I just updated the 2.0.6 release and my gecko model which I have printed hundreds of times doesn't stick because ABL does not compensate or incorrectly compensates.

This is a small bed with a thick borosilicate glass, and yet I'm seeing over 0.9mm difference in a 2cm distance on the model.

I will try go back in earlier branches to when this was introduced

minosg commented 4 years ago

Just a quick update. I used previous tags and tried the 5.0.3 and 5.0.4 and the bug fix branch at commit 378b5685b which is updating the tcmstepper library

503, and 504 are applying corrections appropriately but the bug fix did not.

sjasonsmith commented 4 years ago

@minosg are you saying that problems appeared with that specific commit?

minosg commented 4 years ago

No I am still trying to pinpoint the commit but there are literally hundreds. I just happen to have several branches in different points in bug fix, so I can easily triage changes and this is what I tested so far.

Somewhere between April and July a commit made this issue appear. I do not know why it was not caught earlier so it could be a configuration or bed shape which triggers it.

Since we are dealing with positive and negative float point math here, there are a million ways to go wrong.

LongDogGuy commented 4 years ago

@minosg can you recommend a specific build we can fall back to use until this gets sorted out? I (and I'm sure others), are completely blocked until this gets resolved. Not everyone needs the latest features, just something that is reliable.

minosg commented 4 years ago

@LongDogGuy as i mentioned above and as I have confirmed with testing over the weekend the older releases are fine.

2.0.5.3 and 2.0.5.4 properly calibrate for auto bed leveling. Github tracking and 2.0.6 do not.

minosg commented 4 years ago

@OC-Rookier out of curiosity what slicer do you use?

OC-Rookier commented 4 years ago

I use Cura 4.6.1. It's an .appimage on Linux, if that matters. Worked perfectly fine for the 1.1.5 board and Marlin 1.1.x.

minosg commented 4 years ago

Thanks, then it's definately not a slicer issue. During my testing I bumped onto a prusaslicer issue which messes with extrusion widths.

Have you tried with 2.5.0.4 release?

OC-Rookier commented 4 years ago

I assume you mean 2.0.5.4?

minosg commented 4 years ago

Yes sorry.

OC-Rookier commented 4 years ago

I don't know if I can. My board (SKR Mini E3 V2) does not appear in boards.h, so there might not be any support for it.

minosg commented 4 years ago

Oh right I I'm sorry. I was testing in an 1.2 which worked. Unfortunately you may be stuck until we figure this out

github-actions[bot] commented 4 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

schleir commented 4 years ago

Any update here. I am having the same issue. I can help with any logs that are needed.

salacpavel commented 4 years ago

The problem here is that this issue, despite existing and confirmed, is closed because dumb-ass automated closure process - nobody is/will be working on it.

thisiskeithb commented 4 years ago

Stale bot has instructions to keep it open:

Remove stale label / comment or this will be closed in 5 days.

OC-Rookier commented 4 years ago

My bad. Forgot about this issue and just had to be very careful not to bump the bed leveling knobs. I have since updated to 2.0.6.1, and have not tested this issue in this release.

schleir commented 4 years ago

I can confirm that this issue is present in 2.0.6.1

thisiskeithb commented 4 years ago

For everyone reporting that they have this issue, please follow the steps exactly as described in this comment: https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318

schleir commented 4 years ago

@thisiskeithb

I followed the steps mentioned and printed a simple level test, below is the gcode that I used. I find that the mesh is generated fine, but the print is not uniform and something is off with ABL. My printer uses skr mini e3 v2.0

first_layer.gcode.txt

Here is the terminal logs from my printer - serial.log

Here is the configs used for the firmware:

It uses latest 2.0-bugfix commit that I could find today "82e602c847e248bebc3357405f068fff27fe4537"

Please let me know if you need more logs to fix the issue.

DistortedDesigns commented 4 years ago

I can confirm that ABL is not working. I just installed the latest version of marlin bug fix on my 1.4 turbo and I have a TFT35 V3. I enabled ABL with M420 S1, ran a 5x5 bi-linear, M500 to save. My cura has the code added to recall a saved mesh. I ran the 5 square adhesion test print and there were definite issues. My bed is no more than 0.1 off but no adjustments happening. I do have restore after G28 on in firmware as well.

muvox commented 4 years ago

I have this issue on my SWX1 (MKS Gen L v1) with ABL bilinear aswell. I tried bugfix 3~ weeks ago and one 5~ days ago. My probes standard deviation was 0.04. I checked all my axis, belts and wheels multiple times. I tried 3 by 3 and 5 by 5 grid. I re-measured my probes x and y offset and set them accordingly. I've tried altering manual x and y home position. I've tried altering probing speeds. I've tried disabling BLTOUCH_HS_MODE 5V mode. I've tried with and without adaptive step smoothing. Overall I've tried around 15 different configuration combinations yet the issue is always the same. Topleft corner seems a tad too close to nozzle. Bottom left corner is pretty much perfect and all the rest of the points are too far away from the nozzle to stick properly. Unfortunately I've turned to MBL cannot post logs atm. Posting any info i could just in case it helps at all. Will see if i get the time to flash latest bugfix with all the debugging stuff enabled in the coming weeks. Start gcode is G28, followed by G29.

schleir commented 4 years ago

I do see some z-compensation as I can see small turns in z coupler during first layer.

It's just that the compensation is not correct or precise enough to produce consistent first layer.

Can this https://github.com/MarlinFirmware/Marlin/issues/18369

be causing the issue? (MIN_STEP_PER_SEGMENT set too high to 6)

LarrxX commented 4 years ago

Just to confirm that I'm also having this problem with 2.0.6 and 2.0.7 releases. Bed leveling is not compensating properly and I'm getting non uniform first layer on Ender 3 Pro.

Leveling with :

M140 S60 ;set bed temperature to 60
M105 ;report temperatures
M190 S60 ;wait for bed to reach temperature
G28 ;home all axes
G29 ;bed leveling
M140 S0 ;set bed temperature to 0
M500 ;store leveling in EEPROM

And then printing with:

G28 ; Home all axes
M420 S1 ; Load bed leveling topography

Produces total rubbish. And if I print with:

G28 ; Home all axes
G29 ; Bed leveling

I get better results, but still not tcorrect.

Happy to provide logs if needed.

schleir commented 4 years ago

LarrxX,

Interesting, do you have success with G28 G29 as start g code?

I tried using both start g code and still have inconsistent first layer.

Option 1

Level separately with G29 and save with M500

G28 M420 S1

Option 2

G28 G29

The troubleshooting steps mentioned above recommends to use Option 2 and I have attached logs using Option 2, i.e. g28 G29 before each print.

LarrxX commented 4 years ago

I have inconsistent first layer in both cases, but they are not the same. It's really weird, because there is some Z axis compensation going on, just not as it should be.

I tried flashing 2.0.5.4, same problem persists.

schleir commented 4 years ago

Got it. Sounds like the same issue I am facing.

Can you also please post logs after following steps listed here:

https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318

LarrxX commented 4 years ago

Edit: My results below are wrong. I had a faulty Z lead screw coupler which led to a drift in Z when leveling the bed.

Ok here are my logs with the latest 2.0.X-bugfix.

Here are my config files: Configuration.h.txt Configuration_adv.h.txt

Following the procedure in https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318 I have the following log: leveling.log

Then tried printing this one layer file: Calibrator.gcode.txt

Case 1: Here is the log if I do G28then G29 during the print: G28_G29.log

Case 2: Here is the log if I do my leveling first, store it with M500then print using M420: G28_M420.log

And here is what my bed topology looks like: visualizer

In both cases there is some Z-axis movement.

I don't get the same results on the print: Case 1: The print is OK in the back and squished in the front, same as the topology of the bed (as if there was no compensation at all). Case 2: The print is OK in the front, and not sticking at all in the back (as if the highest level compensation was applied everywhere).

EDIT: Reuploaded both print logs with verbose mode correctly set.

minosg commented 4 years ago

For anyone wanting to test for this bug, I have found out that the Gecko model I have been using to debug other patches is an excellent test print.

https://www.thingiverse.com/thing:3663547

While printing a test cube or any simple shape based print may work, forcing the first layer to do complicated moves is guaranteed to trigger it.

I thought the 6.0.1 release had fixed the leveling issue, but I was printing benchies and test cubes. When tried this model, the tail was always printed on the air.

Has anyone else noticed random layer shifting when printing in Marlin 6.0.0+? While everything works as expected in 5.X.XX versions, the same Gecko model gcodes is sometimes y-shifted in newer versions, and I was wondering if that bug causes compensation applied at the wrong layer, or weather the matrix gets corrupted ( Even though that would result in Moire patterns )

schleir commented 4 years ago

@thinkyhead @thisiskeithb - There are 4-5 sets of logs from the troubleshooting steps (https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318) provided in this issue by different people.

Are there any other required information?

boelle commented 4 years ago

Are there any other required information?

no but a barrel full of patience will not hurt, after all marlin is free and all work on it at their free time

schleir commented 4 years ago

Yes, definitely agree :)

LarrxX commented 4 years ago

I opened a new issue #19937. It could explain the behavior seen in this issue. Could the other people having this problem test and confirm?

LarrxX commented 3 years ago

I had a loose Z lead screw coupler which caused a drift in the Z axis when leveling the bed. By resolving it in issue #19937 it solved my problem for this issue.

Hope this helps.

thestephenmarshall commented 3 years ago

After struggling with this for many months, I too noticed a drifting z lead screw which was characterized my the z occasionally becoming out of sync. That was not all however. You see I also had a twist in my X axis that was only occurring at certain positions the the X/Y matrix. The z lead screw was only barely able to move independently with a little force and the X twist.. well you couldn't easily measure that given we are talking about fractions of a millimeter.. I had to go with my suspicions and the feedback I found here I this repository. The machine was a POS MP Maker-select v2.1 frame which are cheap garbage. I printed an entire solution for the X axis which removed all wiggle room except for the normal amount needed for the lead screws the tightened those down like my life depended on it. BLTouch working like day 1. Did I mention the frame is crap? Ok good luck.

CircuitSetup commented 3 years ago

I'm also experiencing this issue since updating to v2.0.6 on an SKR v1.3 I've updated to the latest bugfix release and am still seeing the same results. It seems to be worse when the bed is extra slanted. I can confirm that some correction is occurring since the z motor is moving when printing.

boelle commented 3 years ago

since updating to v2.0.6

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

CircuitSetup commented 3 years ago

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

Right, I'm currently using the latest bugfix files (as of 2 days ago), and am still seeing the problem. If I manually level the bed, then run ABL, the problem isn't as severe.

thestephenmarshall commented 3 years ago

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

Right, I'm currently using the latest bugfix files (as of 2 days ago), and am still seeing the problem. If I manually level the bed, then run ABL, the problem isn't as severe.

Then you likely have a hardware issue. I've found ABL + BLTouch to be completely unforgiving which is also why it works so well when there are no mechanical issues. So that I can offer some kind of help, can I also ask whether you are running dual z? If so, one other thing I noticed when ABL wasn't working right for me was that no way in hell could I get a true reading from G34 Z Stepper Auto-align. Sure, the output claimed to be within 0.01mm which ultimately was the target... but using the simple tried and true method of placing an object under each side of the X axis yielded un-level results every time. After fixing the mechanical issues on my machine ABL G29 and G34 are working perfectly with the latest bugfix via bilinear.

One last edit: the nail in the coffin here might be finding out that after say 24 hours of printing your manually leveled bed mesh is somehow now incorrect (left side too low or high, etc.). This made it clear to me that something was shifting or inconsistent with the machine. The difference was too small to perceive with the naked eye.

MarlinFirmware / Marlin