Bilinear bed level doesn't compensate properly.

cbitterfield commented 7 years ago

Issue: Bed leveling (Bilinear) cannot compensate for 400-600 microns (even pitch). Release: RC BugFix (RC8/Wookie) Nozzel v probe(X 33mm, Y -14mm, Z 1.5mm) Test Performed: I ran several G29 reports and did a surface plot. My back right corner of the bed is 0,0. Left front is lower than back right By 400-600 microns After auto bed leveling. The variation of the bed height is not compensated for. Printer prints in middle 40MM OK, but any print that is 180MM (X scale) or (Y Scale) demonstrates unprintable variation.

Tests Performed (Used 3x3 points, 5x5 points, and 10x10 points). Surface plot shows variations in bed height (Attached) Surface Plots for bed leveling.xlsx

What I notice is that the bed leveling seems to apply a single compensation factor.

How do I verify what compensation is working for bed leveling? Left to right variation is 400-600 microns.

psavva commented 7 years ago

Please try test this again using the latest RCBugFix branch.

I'm using this today with no issues

cbitterfield commented 7 years ago

Is there a testing methodology that will help?

ghost commented 7 years ago

Try, try, try again.

cbitterfield commented 7 years ago

I am using the 12/21 RC Bugfix pull. I don't see any newer files. As the print nozzel is in motion; how do I see the amount of compensation. That should be changing as the carriage moves. Does the sensor need to be closer to the nozzel than 33mm.

ghost commented 7 years ago

I would verify the sensor reading by repeatability tests. 400-600 microns is quite a bit.

33mm sensing distance? Wow.. Closeness only matters on the sensor or probe used. And the accuracy of that probe at X distance.

Roxy-3D commented 7 years ago

The 'Fade Height' concept is in play with the Bi-Linear Mesh leveling. If you are above the fade height, you won't see any correction. Move the nozzle down to 1mm above the bed. When you move around at that height you should see corrections being applied.

nesalkiN commented 7 years ago

What is the fade height and how do you read the current value?

cbitterfield commented 7 years ago

->M503

<-echo:Steps per unit: <-echo: M92 X88.00 Y88.00 Z2268.00 E100.00 <-echo:Maximum feedrates (mm/s): <-echo: M203 X500.00 Y500.00 Z5.00 E45.00 <-echo:Maximum Acceleration (mm/s2): <-echo: M201 X3000 Y3000 Z100 E10000 <-echo:Accelerations: P=printing, R=retract and T=travel <-echo: M204 P2000.00 R2000.00 T3000.00 <-echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s) <-echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.40 E5.00 <-echo:Home offset (mm) <-echo: M206 X0.00 Y0.00 Z0.00 <-Auto Bed Leveling: <-echo: M420 S0 <-echo:Material heatup parameters: <-echo: M145 S0 H180 B70 F0 <- M145 S1 H240 B110 F0 <-echo:PID settings: <-echo: M301 P22.20 I1.08 D114.00 <-echo:Filament settings: Disabled <-echo: M200 D3.00 <-echo: M200 D0 <-echo:Z-Probe Offset (mm): <-echo: M851 Z-0.94

cbitterfield commented 7 years ago

M48 X100 Y100 S9 P10 <-Finished! <-Mean: 0.940123 Min: 0.939 Max: 0.941 Range: 0.002 <-Standard Deviation: 0.000475

cbitterfield commented 7 years ago

<-Bilinear Leveling Grid: <- 0 1 2 3 4 5 6 7 8 9 <- 0 +0.21 +0.25 +0.25 +0.22 +0.18 +0.13 +0.08 +0.06 +0.00 -0.09 <- 1 +0.25 +0.28 +0.27 +0.24 +0.21 +0.15 +0.10 +0.08 -0.01 -0.10 <- 2 +0.30 +0.30 +0.29 +0.24 +0.18 +0.13 +0.06 +0.02 -0.01 -0.09 <- 3 +0.31 +0.31 +0.28 +0.25 +0.18 +0.12 +0.05 +0.01 +0.16 +0.25 <- 4 +0.33 +0.33 +0.31 +0.25 +0.18 +0.13 +0.06 -0.02 -0.04 +0.14 <- 5 +0.34 +0.35 +0.32 +0.27 +0.21 +0.15 +0.08 -0.00 -0.08 -0.13 <- 6 +0.34 +0.33 +0.30 +0.25 +0.19 +0.13 +0.05 -0.03 -0.10 -0.18 <- 7 +0.35 +0.32 +0.30 +0.26 +0.21 +0.15 +0.08 -0.01 -0.10 -0.18 <- 8 +0.34 +0.34 +0.30 +0.27 +0.20 +0.13 +0.06 -0.02 -0.11 -0.19 <- 9 +0.35 +0.33 +0.30 +0.27 +0.22 +0.15 +0.07 -0.01 -0.11 -0.20

cbitterfield commented 7 years ago

Changed mode from Z Probe and Endstop to Z Probe Only.

Roxy-3D commented 7 years ago

M48 X100 Y100 S9 P10 <-Finished! <-Mean: 0.940123 Min: 0.939 Max: 0.941 Range: 0.002 <-Standard Deviation: 0.000475

Those are very good numbers. I'm jealous. But you should physically level your bed better. You want to lower your left side .15 mm. Once you do that... If you regenerate that map, I think you might see a twist in your bed.

What is the fade height and how do you read the current value?

Fad Height is a concept where the mesh correction is applied at full strength (to fully correct the error) when the Z Height is 0.000 mm. But as the Z Height increases, the amount of correction being applied gets to be less and less. When the nozzle gets to the 'Fade Height', no correction is applied. This keeps any errors in the bed topography from being projected to the top layer of the print. (The concept was pioneered in the UBL branch at: https://github.com/MarlinFirmware/Marlin/tree/devel-ubl )

brainscan commented 7 years ago

This might be a stupid question but shouldn't the fade height still give full correction up to a certain height, as in the first layer height? If I tried to use a big nozzle and fat layers would it be fading while trying to put down the first layer? I'm wondering if that's what was going wrong when I tried using it for MBL and things went very wrong.

zelogik commented 7 years ago

@Roxy-3D : Seem like the Fade-height seem like a killing feature for me, wondering if that feature will be merged in the main Marlin branch (or RCBugFix) soon, or the UBL branch will be forever in a separate branch.

cbitterfield commented 7 years ago

update: There was an issue with the Zmin (Switch) and the ZProbe. There needs to be better logic. I heard it clicking during the bed leveling. I changed the option in configuration.h to eliminate the dual feature. I think there needs to be better logic implemented as I left the Z limit switch operational as a safety mechanism.

After correcting that these are the numbers:

M48: <-Finished! <-Mean: 1.159391 Min: 1.157 Max: 1.161 Range: 0.004 <-Standard Deviation: 0.001010 <-

<-Bilinear Leveling Grid: <- 0 1 2 3 4 5 6 7 8 9 <- 0 +0.30 +0.32 +0.35 +0.30 +0.24 +0.18 +0.16 +0.13 +0.07 -0.01 <- 1 +0.34 +0.35 +0.35 +0.32 +0.27 +0.21 +0.16 +0.19 +0.07 -0.03 <- 2 +0.41 +0.38 +0.36 +0.32 +0.26 +0.20 +0.13 +0.10 +0.06 -0.02 <- 3 +0.44 +0.41 +0.39 +0.33 +0.27 +0.21 +0.14 +0.08 +0.14 +0.12 <- 4 +0.44 +0.41 +0.38 +0.33 +0.28 +0.19 +0.12 +0.05 +0.01 -0.02 <- 5 +0.47 +0.44 +0.41 +0.36 +0.30 +0.24 +0.15 +0.07 +0.00 -0.07 <- 6 +0.45 +0.43 +0.39 +0.36 +0.30 +0.21 +0.13 +0.05 -0.03 -0.11 <- 7 +0.46 +0.43 +0.41 +0.36 +0.31 +0.24 +0.14 +0.06 -0.04 -0.13 <- 8 +0.44 +0.42 +0.39 +0.34 +0.29 +0.21 +0.12 +0.04 -0.05 -0.14 <- 9 +0.45 +0.42 +0.40 +0.37 +0.30 +0.23 +0.14 +0.05 -0.04 -0.15 <- <-G29 uncorrected Z:10.94 <- corrected Z:11.08

Now I am going to run a test print.

cbitterfield commented 7 years ago

Better results: However left side is still too low. I am assuming fade height is to blame?

Changed Z offset from -0.94 to -1.00 After that, the next text will be to changed the bed height manually and retry.

<-Bilinear Leveling Grid: [431.128]

<- 0 1 2 3 4 5 6 7 8 9 [431.128]

<- 0 +0.16 +0.17 +0.19 +0.13 +0.08 +0.02 -0.01 -0.06 -0.12 -0.19 [431.128]

<- 1 +0.21 +0.22 +0.20 +0.16 +0.10 +0.05 -0.01 -0.03 -0.12 -0.20 [431.128]

<- 2 +0.25 +0.24 +0.20 +0.15 +0.09 +0.02 -0.04 -0.08 -0.12 -0.20 [431.128]

<- 3 +0.28 +0.25 +0.23 +0.18 +0.13 +0.06 -0.01 -0.07 -0.07 -0.09 [431.128]

<- 4 +0.32 +0.28 +0.26 +0.20 +0.14 +0.08 +0.00 -0.07 -0.13 -0.16 [431.128]

<- 5 +0.31 +0.29 +0.27 +0.22 +0.15 +0.08 +0.00 -0.08 -0.15 -0.22 [431.128]

<- 6 +0.34 +0.32 +0.27 +0.24 +0.15 +0.09 -0.00 -0.08 -0.16 -0.24 [431.128]

<- 7 +0.34 +0.30 +0.29 +0.24 +0.17 +0.11 +0.01 -0.08 -0.16 -0.25 [431.128]

<- 8 +0.35 +0.33 +0.30 +0.24 +0.16 +0.10 +0.00 -0.07 -0.17 -0.25 [431.128]

<- 9 +0.35 +0.35 +0.30 +0.25 +0.19 +0.13 +0.03 -0.06 -0.16 -0.26 [431.128]

<- [431.128]

<-G29 uncorrected Z:11.00 [431.128]

<- corrected Z:11.26 [431.128]

Roxy-3D commented 7 years ago

This might be a stupid question but shouldn't the fade height still give full correction up to a certain height, as in the first layer height? If I tried to use a big nozzle and fat layers would it be fading while trying to put down the first layer? I'm wondering if that's what was going wrong when I tried using it for MBL and things went very wrong.

It can be implemented any way people want it to be. But my thinking on it was the whole purpose of raising and lowering the nozzle on the first few layers is to allow good adhesion on the print surface. After you have good adhesion, it gets less and less important to follow the bed's contour as you go further up. But it didn't feel reasonable to just turn it off. It felt safer to slowly back out the amount of correction being applied. Otherwise, if you had a large error at some place in your bed that the mesh was correcting, suddenly, that full error is exposed and you might not get good adhesion to the print when you turned off the correction.

And in fact, having a flat surface on the top of the print is probably preferred. If you keep applying the correction at full strength as you go up your part will actually end up too big. On the lower side, the nozzle will be lowering to fill in the dips. And on the top surface the nozzle will be raising to follow the bumps in the bed surface. By fading out the correction, you get less distortion in your part. If you do want the correction to be applied all the way up, you can set a very large fade height that you will never reach.

I'm open to any suggestions. But that is what I was thinking when I coded that feature.

Seem like the Fade-height seem like a killing feature for me, wondering if that feature will be merged in the main Marlin branch (or RCBugFix) soon, or the UBL branch will be forever in a separate branch.

Is the Fade-Height 'killing' your print? Is that what you mean? Fade-Height does work correctly in the UBL branch. And you get flexibility on how it is set without rebuilding the firmware. You can set it arbitrarily large or small so you get good control of how it behaves over the full height of your print.

I have not loaded or used the bi-linear mesh leveling in RC-8. I haven't had time to use it. But I can assure you that the Fade Height feature does work correctly in UBL and if you are willing to bring that up I'll help you work through any issues. The goal of UBL is to consolidate all of the Auto Bed Leveling schemes and to make them all available at all times to all machine types. It is very possible that after RC-8's RCBugFix gets promoted to a 'Stable Release', the main development branch will become the UBL code base. If that happens, sometime in the distant future (1 year???) UBL will become the next 'Stable Release'. Even if that doesn't happen, many of the features in UBL are being proven to be very desirable and they will migrate into to the main code bases (just like Fade Height did).

brainscan commented 7 years ago

I understand what you're saying about not wanting to just switch off the levelling but is the full correction only applied at Z0.0? Its impossible to print anything at Z0.0 so really the full correction should start at first layer height and then fade away over a given amount. If the correction is already being faded during the first layer you'll presumably never get a consistent first layer as some areas will be over extruded and others under. Sorry if I've not thought it through correctly.

Roxy-3D commented 7 years ago

I understand what you're saying about not wanting to just switch off the levelling but is the full correction only applied at Z0.0?

Yes. And in fact, because the printer prints the first layer at say .20 mm the full correction is never really applied. That is well within the 'margin for error' with a default Fade Height of 10mm.

Its impossible to print anything at Z0.0 so really the full correction should start at first layer height and then fade away over a given amount.

Yes. What you say is true. But I deliberately did not do this. The reason is it would add several more floating point terms to the calculation. Especially when we get up and running on a 32-Bit platform we will have the processing power to be more 'pure'. But the honest truth is, a 5% difference doesn't matter that much to how the filament spreads out. And... With the QUICK ACCESS TO Z BABYSTEPPING, the user gets to dial in exactly how they want the filament squished for a perfect first layer. So for right now... Even though mathematically it is easy to add... It isn't in there.

If the correction is already being faded during the first layer you'll presumably never get a consistent first layer as some areas will be over extruded and others under. Sorry if I've not thought it through correctly.

No... As it turns out, you can do a simple experiment and prove this isn't true. If you get a mesh perfectly defined, you can deliberately corrupt one point of it. If you raise or lower one mesh point by 10% you will still get good adhesion on something that resides on that point. There is more than a 5% margin for error on height to get good adhesion. You very well may see the filament not squished the right amount. But there will be plastic stuck to the bed for the next layer to build upon. But then you combine in the ability to do Z-Baby-Stepping on the first layer and it is possible to get 100% adhesion on the entire bed every time.

And seriously... I'm not saying "I'm right!" I'm trying to communicate how I'm thinking about the problem. This is a 'Development Branch'. That means the concepts being worked on it are not fully proven or debugged. I'm open to making any change that makes sense!

UPDATE: And actually... There are some self correcting variables in the equation. Because of how the mesh is automatically probed, but then edited based upon the G26 Mesh Validation Pattern, it is very possible that any point that is off by 5% gets 'corrected'. It may be that UBL isn't printing the first layer with an error of 5%. Because the user gets to edit the mesh to perfection, it is possible the user's mesh is asking for 105% correction at Z=0.000mm but on the first layer at a height of .20mm the correction is dropping down to 100%.

brainscan commented 7 years ago

For me baby stepping is not helpful at all, I don't want to have to baby step up and down for the whole first layer, that's what I want levelling for. Well for me levelling seems to work without the fade and doesn't when I've tried to use it so maybe 5-10% makes a bigger difference on my printer. Also never having a consistent thickness just ends up messing with the next layer. Sorry i thought it might be easy to add a no fade until height option but as I can't code I can't really help there. To me a perfect first layer isn't one that's just stuck, it's one has a consistent height and thickness. Maybe I'll have to wait for 32bit Marlin if it's not currently possible.

Blue-Marlin commented 7 years ago

@brainscan

o me a perfect first layer isn't one that's just stuck, it's one has a consistent height and thickness.

To me the perfect top layer is flat, it is not bed shaped.

There is a good solution available to fulfill both requirements. Use a flat bed!.

Besides of that. Do you really need to always 'full quote' the posting you are answering to.

zelogik commented 7 years ago

@Roxy-3D: No a killing feature, is a wonderful/perfect feature for me :)

As my printer have Z belt axis, with 1/2 step, the resolution is low on Z, (0.025mm) so, the downside is that I have vertical "glitch" on all the print with Z bilinear leveling enabled (when Z move in accordance with Z map) The bed is not really flat, and for me, the first layer need to just stuck on the bed, and got a perfect top layer and don't have all that vertical "glitch". So this fade feature seem really good! But with that branch (UBL) I don't know if there is some other cool feature that working well for me (SMOOTH). edit: Oups don't have seen that Fade height was added to RCBugFix.

brainscan commented 7 years ago

Sorry, I forget replying from email does that, I will stop. Yes a flat bed would be great but over time my aluminium bed is becoming less and less flat and I can't afford to keep replacing it. I also agree a perfect top layer is flat and I'd really like to use the fade feature to get that but if it makes the first layer less consistent then I'm not sure it will always work when I switch nozzle size and layer height. I haven't tried playing too much with different settings as I had to replace all the kapton tape last time so it may be that I was using totally the wrong settings or had sent some stupid command.

cbitterfield commented 7 years ago

Is there a logic to the Bilinear bed leveling? A process flow or something?. What I get is a consistent problem. If I adjust manually, the printer un-adjusts to the same error. Always the same left is lower than right. (0,0) back right.

What is a good method for testing and diagnosing the issue?

I have seen bed leveling demonstrations where the bed is at 35 degrees and it still prints. So with less than 1mm variation on a slope; why doesn't it compensate properly?

Is there a debug mode that will show the Z axis compensation in real time?

Roxy-3D commented 7 years ago

No... But that could be added. The problem is anything like that is going to eat CPU cycles.

May I suggest you bring up the UBL Bed Leveling System? I know that code inside and out. If you run into a problem, I'll be able to quickly assist you. The problem right now is ThinkyHead is outside the country and I am not familiar with that code. So it is difficult for me to jump in and help.

cbitterfield commented 7 years ago

OK; I'll load that code branch today. The largest issue for me is a repeatable Q/A test that is meaningful. I am starting to work out that logic. I am trying to figure out what is a constant and what is a variable. So far there are too many variables to work from. I assume my X & Y carriage are constants. But I am starting to re-think that. The question that seems most appropriate is:

[Fact] I have the problems described in the first layer. Therefore, I can see that "Fade Height" is the issue.

If the bed is not level or if it is and the carriage has some variation, is the problem the same or different?
If the bed is not level to begin with, why would you fade the correction presumably it remains the same out of level amount all the way.
What is a repeatable test that will help with troubleshooting? What information will help?
As a feature sometime, it might be good to put the sensor where the nozzel is and map the bed for a better troubleshoot.
Is the proximity to the Nozzel responsible for variations? (Mine is 33mm to the right of the nozzel). I have ordered 4 different proximity sensors that are much smaller to see about the proximity issue.

cbitterfield commented 7 years ago

Latest Bed Leveling Report

0,0 back right corner

cbitterfield commented 7 years ago

Where in the devel-ubl code is the hidden probe define(s) AUTO_BED_LEVELING_FEATURE or Z Servo? I have a fixed probe and I am getting there error "There can only be ONE" :)

nzinov commented 7 years ago

Speaking of Fade Height settings in RC8. I looked through the code and apparently it is set by M420 command (which is for Mesh BL) even if MBL is off and affects ABL. However, it seems that it is not stored to EEPROM. Also it is not displayed in M503 output.

EDIT: I see now that M420 is both for MBL and ABL. So the problem is only with saving and displaying.

nzinov commented 7 years ago

Just tested leveling by putting a coin on the bed while doing G29. This gave me 2 points with high z-value:

Bilinear Leveling Grid:
      0     1     2     3     4     5     6     7     8
 0 +1.28 +1.08 +0.51 +0.11 +0.03 +0.16 +0.22 0.00 0.00
 1 +0.82 +0.12 -0.21 -0.31 -0.18 -0.06 -0.04 -0.08 +0.14
 2 -0.09 -0.40 -0.45 -0.37 -0.25 -0.08 -0.11 -0.23 -0.07
 3 -0.22 -0.32 -0.36 -0.24 -0.15 -0.02 -0.13 -0.28 -0.34
 4 -0.40 -0.34 -0.37 +2.87 +3.01 -0.03 +0.05 -0.03 -0.11
 5 -0.19 -0.13 -0.15 -0.08 -0.03 -0.01 +0.05 -0.07 -0.02
 6 -0.17 -0.02 -0.01 +0.04 +0.05 +0.08 +0.04 +0.01 +0.09
 7 +0.06 +0.15 +0.16 +0.10 +0.04 +0.00 -0.11 -0.15 -0.01
 8 +0.24 +0.17 +0.19 +0.12 +0.06 -0.01 -0.09 -0.14 -0.09

(See row 4)

When I move head near the bed it "jumps" in the correct place. I also set the fade_height to 30mm to test fading - and it worked as supposed. I am running recent RCBugFix. ALL WORKS

cbitterfield commented 7 years ago

I am thinking there is an issue with ZMin Endstop and ZProbe where it hits the endstop and needs to move further on that axis. Trying to configure the printer with only a Z probe.

MarlinFirmware / Marlin

Bilinear bed level doesn't compensate properly. #5627