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.04k stars 19.15k forks source link

[1.1.x - Bugfix] - UBL - a problem with the printout dimension in Z #10520

Closed WojRep closed 5 years ago

WojRep commented 6 years ago

I am not a specialist, but I use several printers at one time and I wanted to prepare them for printing on layers as low as 0.2mm.

The prints came out satisfactorily on the center of the printer table for 100x100mm objects, so I expected a seamless UBL implemation.

After a few days of struggling with the calibration and settings, I found the reason for my problems with printouts.

Configuration of gcode for UBL according to the instructions from the documentation.

In principle, this is one problem, the prints were too low in relation to the project even by a few millimeters.

My map (one of many, an example)

< 08:54:09: Bed Topography Report:
< 08:54:09:     ( 20,152)                                                                              (194,152)
< 08:54:09:         0       1       2       3       4       5       6       7       8       9      10      11      
< 08:54:09: 11 | +2.608  +2.410  +2.574  +2.514  +2.529  +2.493  +2.470  +2.122  +2.399  +2.364  +2.454  +2.318 
< 08:54:09:    |
< 08:54:09: 10 | +2.604  +2.468  +2.570  +2.510  +2.525  +2.489  +2.466  +2.244  +2.421  +2.398  +2.450  +2.352 
< 08:54:09:    |
< 08:54:09:  9 | +2.600  +2.527  +2.567  +2.506  +2.521  +2.485  +2.463  +2.365  +2.442  +2.431  +2.446  +2.386 
< 08:54:09:    |
< 08:54:09:  8 | +2.546  +2.586  +2.563  +2.502  +2.455  +2.444  +2.446  +2.486  +2.463  +2.465  +2.417  +2.419 
< 08:54:09:    |
< 08:54:09:  7 | +2.530  +2.494  +2.484  +2.461  +2.438  +2.465  +2.417  +2.432  +2.422  +2.374  +2.401  +2.340 
< 08:54:09:    |
< 08:54:09:  6 | +2.476  +2.416  +2.430  +2.507  +2.409  +2.349  +2.439  +2.503  +2.418  +2.457  +2.385  +2.312 
< 08:54:09:    |
< 08:54:09:  5 | +2.410  +2.424  +2.389  +2.416  +2.393  +2.320  +2.360  +2.362  +2.364  +2.391  +2.306  +2.295 
< 08:54:09:    |
< 08:54:09:  4 | +2.381  +2.370  +2.372  +2.350 [+2.352] +2.329  +2.343  +2.371  +2.323  +2.350  +2.327  +2.266 
< 08:54:09:    |
< 08:54:09:  3 | +2.314  +2.379  +2.381  +2.396  +2.310  +2.300  +2.327  +2.317  +2.306  +2.358  +2.336  +2.263 
< 08:54:09:    |
< 08:54:09:  2 | +2.248  +2.288  +2.340  +2.342  +2.357  +2.246  +2.323  +2.300  +2.290  +2.317  +2.307  +2.296 
< 08:54:09:    |
< 08:54:10:  1 | +2.219  +2.271  +2.273  +2.301  +2.303  +2.305  +2.269  +2.246  +2.349  +2.301  +2.265  +2.242 
< 08:54:10:    |
< 08:54:10:  0 | +2.178  +2.218  +2.257  +2.222  +2.199  +2.263  +2.253  +2.255  +2.232  +2.297  +2.311  +2.301 
< 08:54:10:         0       1       2       3       4       5       6       7       8       9      10      11      
< 08:54:10:     ( 20, 20)                                                                              (194, 20)

The effect obtained, print too low by more than 2mm.

For the map:

< 08:54:09: Bed Topography Report:
< 08:54:09:     ( 20,152)                                                                              (194,152)
< 08:54:09:         0       1       2       3       4       5       6       7       8       9      10      11      
< 08:54:09: 11 | -1.608  -1.410  -1.574  -1.514  -1.529  -1.493  -1.470  -1.122  -1.399  -1.364  -1.454  -1.318 
< 08:54:09:    |
< 08:54:09: 10 | -1.604  -1.468  -1.570  -1.510  -1.525  -1.489  -1.466  -1.244  -1.421  -1.398  -1.450  -1.352 
< 08:54:09:    |
< 08:54:09:  9 | -1.600  -1.527  -1.567  -1.506  -1.521  -1.485  -1.463  -1.365  -1.442  -1.431  -1.446  -1.386 
< 08:54:09:    |
< 08:54:09:  8 | -1.546  -1.586  -1.563  -1.502  -1.455  -1.444  -1.446  -1.486  -1.463  -1.465  -1.417  -1.419 
< 08:54:09:    |
< 08:54:09:  7 | -1.530  -1.494  -1.484  -1.461  -1.438  -1.465  -1.417  -1.432  -1.422  -1.374  -1.401  -1.340 
< 08:54:09:    |
< 08:54:09:  6 | -1.476  -1.416  -1.430  -1.507  -1.409  -1.349  -1.439  -1.503  -1.418  -1.457  -1.385  -1.312 
< 08:54:09:    |
< 08:54:09:  5 | -1.410  -1.424  -1.389  -1.416  -1.393  -1.320  -1.360  -1.362  -1.364  -1.391  -1.306  -1.295 
< 08:54:09:    |
< 08:54:09:  4 | -1.381  -1.370  -1.372  -1.350 [-1.352] -1.329  -1.343  -1.371  -1.323  -1.350  -1.327  -1.266 
< 08:54:09:    |
< 08:54:09:  3 | -1.314  -1.379  -1.381  -1.396  -1.310  -1.300  -1.327  -1.317  -1.306  -1.358  -1.336  -1.263 
< 08:54:09:    |
< 08:54:09:  2 | -1.248  -1.288  -1.340  -1.342  -1.357  -1.246  -1.323  -1.300  -1.290  -1.317  -1.307  -1.296 
< 08:54:09:    |
< 08:54:10:  1 | -1.219  -1.271  -1.273  -1.301  -1.303  -1.305  -1.269  -1.246  -1.349  -1.301  -1.265  -1.242 
< 08:54:10:    |
< 08:54:10:  0 | -1.178  -1.218  -1.257  -1.222  -1.199  -1.263  -1.253  -1.255  -1.232  -1.297  -1.311  -1.301 
< 08:54:10:         0       1       2       3       4       5       6       7       8       9      10      11      
< 08:54:10:     ( 20, 20)                                                                              (194, 20)

The print was too high ...

In both cases, the difference between the highest and the smallest element is about 0.3mm and I expected such a difference in the printout.

The solution is to change the height of the print field, so that the map comes out as close as possible to the value 0. It does not satisfy me, I use different panes for the printer table, they differ in height by less than 1mm. Sometimes I use a mirror, sometimes frosted glass (sandblasted), depending on how the bottom print layer should look.

In my opinion, for the calculation in combination with the fade height, the entire map should not be taken, but only the height differences (the lowest point and the highest point) in relation to the center point.

(sorry for my English, write by translator)

Configuration_adv.h.zip Configuration.h.zip

thinkyhead commented 6 years ago

Since you're using UBL, you can use G29 P6 C0 to center all values around the mean (plus 0).

I'm also adding M420 C to do the same for other mesh-based bed leveling systems.

Roxy-3D commented 6 years ago

Since you're using UBL, you can use G29 P6 C0 to center all values around the mean (plus 0). I'm also adding M420 C to do the same for other mesh-based bed leveling systems.

@thinkyhead I've added a little more text to: https://github.com/MarlinFirmware/MarlinDocumentation/blob/master/_features/unified_bed_leveling.md

When ever you run the tools on other documentation pages... Please include that page.

The printer should be able to successfully print a small object at the center of the bed with no bed leveling system active. Most problems bringing up the UBL Bed Leveling system occur when this step has been ignored. It is very important to verify that your configuration.h settings permit this before trying to bring up UBL. Please pay particular attention to your Z_PROBE_OFFSET_FROM_EXTRUDER value. Usually it is best to home the Z-Axis in the center of the bed. But where ever you decide to perform the homing operation, the Z value reported on the LCD Panel (or via M114) should be VERY close to 0.0 mm at the home location when the nozzle is just touching the bed. Failure to calibrate the Z_PROBE_OFFSET_FROM_EXTRUDER value properly will result in dimensional errors later in your printed parts.

@WojRep The problem is your mesh map has all mesh points at fairly large values (-1.5mm). The bed leveling system can work with that. The problem comes in because it is trying to squish (or expand) all the layers within the 'Fade Height'. Because the mesh map is not centered around 0.0 mm in value, the first 10mm of your print is being expanded.

WojRep commented 6 years ago

How should I see the effect of the G29 P6 C0 command ? In my case everything looks the same, before and after the command.

Manual adjustment of the table position does not contribute much to the elimination of the value on + or - (above 1). Only the #define Z_MAX_POS 192 parameter adjustment has a real influence on the grid values to have values close to 0.

My Z_PROBE_OFFSET_FROM_EXTRUDER value is rather good, it allows you to print in the middle of a table without UBL enabled.

Roxy-3D commented 6 years ago

Actually... It is a two part operation... You can find the Mean (Average) Height of your mesh points with a G29 P5. And G29 P6 C x.xxx will shift all the points in your mesh by a certain about. Doing a G29 P6 C0 does nothing because it is shifting everything by 0.00 mm.

WojRep commented 6 years ago

I do not really understand everything ...

Menu LCD, Edit Mesh ... I go through a grid of 5x5 points with a sheet of paper placed under the nozzle .... as I feel the resistance of the card I go to the next point ... and so whole, until the card comes with a delicate resistance.

<  Bed Topography Report:
>  N686 M104 T0 S0 *9
<      ( 20,152)                      (194,152)
<          0       1       2       3       4      
<   4 | -0.055  -0.080  -0.095  -0.185  -0.255 
<     |
<   3 | -0.035  -0.075  -0.090  -0.180  -0.255 
<     |
<   2 | +0.085  -0.020  -0.180  -0.215  -0.380 
<     |
<   1 | +0.100 [+0.015] -0.130  -0.230  -0.390 
<     |
<   0 | +0.120  +0.065  -0.085  -0.220  -0.390 
<          0       1       2       3       4      
<     ( 20, 20)                      (194, 20)

In the start script for each print file I have:

G21
G90
M82
M107
G28 
G1 X100 Y100
G1 Z15
M190 S[first_layer_bed_temperature] ; set and wait for bed temp to be reached
M109 S[temperature] ; set extruder temp and start heating
G29 L1
G29 J
G29 T  

And the effect is as if G29 J completely corrupted the manual editing of the MESH mesh.

<  Bed Topography Report:
>  N686 M104 T0 S0 *9
<      ( 20,152)                      (194,152)
<          0       1       2       3       4      
<   4 | -0.218  -0.167  -0.105  -0.119  -0.112 
<     |
<   3 | -0.219  -0.182  -0.121  -0.134  -0.133 
<     |
<   2 | -0.119  -0.148  -0.231  -0.190  -0.278 
<     |
<   1 | -0.125  -0.133  -0.202  -0.225  -0.309 
<     |
<   0 |[-0.125] -0.104  -0.177  -0.236  -0.329 
<          0       1       2       3       4      
<     ( 20, 20)                      (194, 20)

I always have that in the direction of points X0, Y0 I have a printout about 0.2-0.3mm in the table, at X0, Ymax I'm forced about 0.15-0.2mm, at points Xmax, Y0 and Xmax, Ymax I have a print slightly over the table, about 0.05-0.1 mm.

No matter how many mesh mesh points I have, I have the same regardless of how the mechanical level of the table is the same, no matter how I set the mesh grid manually, I have the same.

This is the second week of my fight against UBL.

I probably do not understand something and I do it wrong ... but I am wondering why it must be so complicated. After all, the appropriate numerical methods and programming code should include it automatically in the default settings.

empakoso commented 6 years ago

This may or may not help. It is based on my experience with bed level sensors. First just to confirm, G29 J is to account for bed tilt each time? I only use that if I am changing the bed surface. It’s not part of my startup code.

If you trust the results of you Z homing sensor then the next bit of information will not be of any value to you. I am only putting this information out there so people can rule out these details.

Second how much do you trust your z homing sensor for repeatable measurements? (seems the “corruption” is in the range of 1/10 of a mm). I found my sensor error in the following ways. A) M48 to check readings B) different locations gave me weird readings C) cycling bed power interferes with my cheap prox sensor D) emi noise interfered with my prox trigger pos. E) mechanically is it solid (delta between nozzle and trigger point) F) M48 options to ‘shake’ the sensor (to include backlash in your mechanical system if you will) G) the final step to getting it all right with my cheap DIY parts was to use anti-backlash thread component for my Zaxis. It’s a spring that keeps two half’s of the nut pressed against the threaded rods. Now that little z raise between measured points isn’t my problem anymore.

Final comment, in measurement studies (metrology) you must be at least 10x’s more precise than the result you are looking for. My rule for my cheap DIY printer that I use is, if I want to keep a steady 1/10 of a millimeter then my M48 results must be a steady 1/100 of. Millimeter in every measurement condition I’ve mentioned above.

I take into account that we are using 10cent proximity sensors on most homing. Knowing that trusted industrial homing switches start at $2’000 and use data networks as trigger signals (not just 5v). In manufacturing robotics 1/10th is pretty awesome repeatability. Having said all my ramblings I summarize by stating these sensors in my experience is like trying to thread a needle in the dark.

empakoso commented 6 years ago

So to uncomplicated your UBL experience, leave the J option out until you have good repeatable printing results from first layer to fade height. Then tackle your bed tilt later as a final polishing step.

thinkyhead commented 6 years ago

G29 P6 C0 does nothing

Actually, it does center the whole mesh on the mean value. It just doesn't shift it up or down in addition to that. However, G29 P6 with no C does nothing to the mesh. It just reports the mean and the sigma.

WojRep commented 6 years ago

I change the table glass, I have different ... depending on what I want to get the texture for the first layer, therefore the thickness of the glass on the table changes. The distance value of the sensor Z (3Dtouch) from the nozzle is always the same. The glass is quite even, max deviation 0.05.

For me, leveling UBL would be really helpful if I run it once when changing the table glass and I do not have to do anything anymore and I still have a lot of work to do.

Do you think that the use of G29 J1 print scripts is correct, to read the table level and adjust the mesh accordingly?

I carried out manual calibration of the entire grid by the M421 commands. I am still improving this grid, but the effects on the first approach are definitely better (using G29 J1). I still have to test it. This printer almost always prints with a table of 100 degrees and a head of 260-275 degrees, so heating is definitely going on and I can not verify it quickly.

Edit: (I think G29 J1 has no effect ... I just did not sit at the printer.)

Let's go back to the problem for a moment, that from one table I have an ironed print, and in the second one in the air ... I can not prove it, but is it possible that the calculations were made on the mirror axis? The calculations for X0 were taken from the grid for the highest Xmax? and so on with the other points? Yes, I know, it sounds like heresy ... but I have a second printer where I set up UBL and there I have an identical problem regardless of the axis setting, or how long I warm up the 3Dtouch sensor (the printer prints only in PLA).

thinkyhead commented 6 years ago

Since you're using two surfaces, are you making a separate mesh for each one?

Did you know…

UBL can save multiple probed meshes to EEPROM and load them back in later. So you can…

When using Bed 1, load Mesh 0. When using Bed 2, load Mesh 1.

WojRep commented 6 years ago

Yes, I know ... (G29 S0 / S1 etc ... )

I can confirm, manually edited mesh mesh and edited using LCD without running in the G29 J startup script, it works satisfactorily. Starting G29 J in my case breaks mesh and the printout is incorrect. On one side of the table, the ironed print, on the other not.

Can you add the ability to measure only one point in the middle of the grid and calculate the grid based on this judgment? - eg G29 J1? (this should work well for 3, 5, 7, 9, 11, 13, 15 point grids)

thinkyhead commented 6 years ago

Is that needed? If your M851 Z probe offset is set correctly and you do G28 (homing Z with the probe) just prior to G29, the mesh will always come out correctly centered around 0.

WojRep commented 6 years ago

Today, I am testing on the second printer, if my problems are solved there, like on the first one, I will recommend my recommendations for the recommended configuration for beginners. I have spent too much time to let this knowledge and experience not be passed on to others.

In terms of explanations ... Usually I do not use the LCD because of a bad rotary encoder and I prefer to use Repieter-Host or prepared configuration files.

I have configuration files:

_init_UBL.gcode

M117 Start UBL
M118 Start UBL
G4 S15;pause
M117 Home XYZ
M118 Home XYZ
G28
M117 going to the top
M118 going to the top
G1 X130 Y130 F8000
G1 Z10 F200
M117 warming up hotend 275 bed 100
M118 warming up hotend 275 bed 100
M190 S100
M104 S275
M117 Do UBL
M118 Do UBL
G29 P1
M117 Koniec Phase 1
M118 Koniec Phase 1

and

_save_UBL.gcode

M117 Show mesh
M118 Show mesh
G29 T
M117 Complete the mesh
M118 Complete the mesh
G29 P3 T
M117 Save UBL
M118 Save UBL
G29 S1
G29 F 10.0
G29 A
M117 Write to EPPROM
M118 Write to EEPROM
M500
M117 Home XYZ
M118 Home XYZ
G28
M117 End UBL
M118 End UBL

Why not in one file .... for two reasons:

  1. After the G29 P1 command, my RAMPS 1.4 and RUMBA are long thinking ... and I usually get a timeout message and no more commands.

  2. One execution of the G29 P3 T command does not solve the problem of mesh filling.

Ad1. - I do not know if this is a mistake only with RAMPS 1.4 and Mega2560, but I have the same printer for two.

Ad2. - Maybe an option that will complete all missing data with one command ??

My starting code for each printout looks like this:

M107
G4 S5
G21
G90
M82
M107
; homing
G28 
G1 X130 Y130
G1 Z15
M190 S100 ; set and wait for bed temp to be reached
M109 S275 ; set extruder temp and start heating
; 
G29 L1
;G29 J ; Probably the perpetrator of the problem with the incorrect printout
G29 T  
; 
G0 X0 Y0 Z0 F9000
G92 E0
G1 E1 F100
G1 Z0.5 F9000
G1 E5.0 F100
G1 Z5.0 F9000
G1 E10.0 F100
G4 S2
G1 Z10.0 F9000
G4 S3
G1 E9 F100
G1 X10 Y0 F9000
G92 E0
G1 F4000
M117 Printing…

I can already confirm that I omitted the G29 J command causes the correct printout on the entire table surface.

Thanks @empakoso, I have saved some time on your hints.

Based on my experience, can not the documentation suggest using G29 J before each printout? I am not the first who uses G29 J by default in the first steps with UBL.

thinkyhead commented 6 years ago

I used to consider G29 J something only for edge cases, but the fact that it ends up filling in the mesh with starting values even where the probe cannot reach is a pretty handy aspect of that function.

Roxy-3D commented 6 years ago

After the G29 P1 command, my RAMPS 1.4 and RUMBA are long thinking ... and I usually get a timeout message and no more commands.

That doesn't sound right. When there are no points that can be probed, it is supposed to return to where the nozzle was located when the probing started.

One execution of the G29 P3 T command does not solve the problem of mesh filling.

It entirely depends on how large your mesh cells are, and how big the X_OFFSET_FROM_EXTRUDER and Y_OFFSET_FROM_EXTRUDER numbers are. It can be no unfilled values (with an inset), 1 row or column, or multiple rows and columns.

I made it so G29 P3 would only fill in one row (and column) at a time to give the user more control. But nobody uses it that way. And not doing the entire unfilled area causes people to not realize they still have unfilled mesh points. Probably, this should be changed to do the entire mesh in one operation.

I used to consider G29 J something only for edge cases, but the fact that it ends up filling in the mesh with starting values even where the probe cannot reach is a pretty handy aspect of that function.

This is an accident. We better check the math works out correctly. (Because NAN's are supposed to propagate through the entire calculation and end up in the result.)

thinkyhead commented 6 years ago

Ah, right, you’d have to pre-fill with zero before G29 J for the tilt to be filled in everywhere.

boelle commented 5 years ago

@WojRep still having issue with latest bugfix 2.0?

boelle commented 5 years ago

@thinkyhead i think we can close this one

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