[BUG] G29 results in random small Z error with BILINEAR leveling

tombrazier commented 2 years ago

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

Yes, and the problem still exists.

Bug Description

At the end of running G29, leveling is applied to current_position. See line 880 of Marlin/src/gcode/bedlevel/abl/G29.cpp

current_position.z -= fade_scaling_factor * bilinear_z_offset(current_position);

When bilinear_z_offset() is called, cached values from the previous mesh are used to calculate the offset. The freshly measured mesh is ignored.

In principle, it might seem like this should not happen because earlier in G29, on line 443, there is:

 if (!no_action) set_bed_leveling_enabled(false);

And set_bed_leveling_enabled() has this:

    #if ENABLED(AUTO_BED_LEVELING_BILINEAR)
      // Force bilinear_z_offset to re-calculate next time
      const xyz_pos_t reset { -9999.999, -9999.999, 0 };
      (void)bilinear_z_offset(reset);
    #endif

However, there are two problems with this way of clearing the cached Z offset values. First, set_bed_leveling_enabled() goes on to call planner.apply_leveling() which calls bilinear_z_offset() again. This is only really a problem if you call G29 when the nozzle is already at the last probing point, e.g. by calling G29 twice in a row.

Second, and more seriously, calling bilinear_z_offset() caches not only the specific nozzle position but the whole mesh cell in which that nozzle position falls (in variable lastg). So there are many scenarios where G29 can use the wrong cached values for some time.

Example behaviour with the default values in Configuration.h: GRID_MAX_POINTS_Y = GRID_MAX_POINTS_X = 3 Bed size is 200 x 200. PROBING_MARGIN = 10

Valid mesh already exists and leveling is applied.

G0 X150 Y150   # this in the same mesh cell as the last probing point
G29            # X150 Y150 gets cached after X-9999.99 Y-9999.99, and current_position ends up wrong
G0 X150 Y150   # this is still in the same cell, so the old mesh values are still being used
G0 X101 Y101   # this is still in the same cell, so the old mesh values are still being used
G0 X50 Y50     # finally the new mesh is used
G0 X150 Y150   # the new mesh is used

Bug Timeline

In 2017, commit 830851df135.

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

Latest bugfix branch

Printer model

No response

Electronics

No response

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

No response

tombrazier commented 2 years ago

I am working on a fix for this. Issue raised just to document it.

andreibobirica commented 2 years ago

I have encountered a similar problem, I use Mesh bed leveling. At the beginning of the print, executing the first instructions of the START GCODE, I found some anomalous behavior. The printhead moves on the Y axis further than it should, on the Z axis higher and when I start the time for printing the leveling is not correct.

Below I am attaching my START GCODE, For example the code

G92 E0
G1 Y165.0 Z0.2 E9.0 F1000.0; intro line

It does not perform the operations at the same time, it first moves the Y axis and then extrudes beyond the Y axis.


; -- START GCODE --
; _TEMP SET_
M140 S[first_layer_bed_temperature] ;Start heating bed
M104 S[first_layer_temperature]     ;Start heating extruder
M190 S[first_layer_bed_temperature] ;Wait for bed to reach temp before proceeding
M109 S[first_layer_temperature]     ;Wait for extruder to reach temp before proceeding
; _END TEMP SET_

;-START PRINTT
G21                                 ;metric values mm
G90                                 ;absolute positioning
M82                                 ;set extruder to absolute mode
M107                                ;start with the fan off
G28 X0 Y0                           ;move X/Y to min endstops
G28 Z0                              ;move Z to min endstops
M420 S1                             ;Activate mesh
M540 S1                             ;Activate EndStop protection

;Select & PURGE First Tool 1
T1
G92 E0                            
G1 Y0 Z2.5 F1000                                  
G1 E[parking_pos_retraction] F1000
G92 E0
G1 Y60.0 Z0.2 E9.0 F1000.0          ;intro line
G1 Y100 E21.5 F1000.0               ;continue line
G92 E0                              ;zero the extruded length again

;Parking Tool 1
M83                                 ;Extruder to Relative MODE
G1 E-{cooling_tube_retraction} F3000  ;Move in cooling position 45mm/s
;cooling moves 6mm/s
G1 E+{cooling_tube_length/2} F360  
G1 E-[cooling_tube_length]  
G1 E+[cooling_tube_length]  ;1
G1 E-[cooling_tube_length] 
G1 E+[cooling_tube_length]  ;2
G1 E-[cooling_tube_length] 
G1 E+[cooling_tube_length]  ;3
G1 E-[cooling_tube_length] 
G1 E+[cooling_tube_length]  ;4
G1 E-{cooling_tube_length/2}
;parking filament  80mm/s
G1 E-{parking_pos_retraction-cooling_tube_retraction} F4800

;Select & PURGE Second Tool 0
M82
T0
G92 E0                         
G1 Y105 Z2.5 F1000                                
G1 E[parking_pos_retraction] F1000
G92 E0
G1 Y165.0 Z0.2 E9.0 F1000.0         ;intro line
G1 Y205 E21.5 F1000.0               ;continue line
G92 E0

;Parking Tool 0
M83                                 ;Extruder to Relative MODE
G1 E-{cooling_tube_retraction} F3000  ;Move in cooling position 45mm/s
;cooling moves 6mm/s
G1 E+{cooling_tube_length/2} F360
G1 E-[cooling_tube_length]  
G1 E+[cooling_tube_length]  ;1
G1 E-[cooling_tube_length] 
G1 E+[cooling_tube_length]  ;2
G1 E-[cooling_tube_length] 
G1 E+[cooling_tube_length]  ;3
G1 E-{cooling_tube_length/2}
;parking filament  80mm/s
G1 E-{parking_pos_retraction-cooling_tube_retraction} F4800  

;Select & PURGE Initial Tool
M82
T[initial_tool] 
G92 E0                         
G1 X3 Y205 Z2.5 F1000                                
G1 E[parking_pos_retraction] F1000
G92 E0
G1 Y145.0 Z0.2 E9.0 F1000.0         ;intro line
G1 Y105 E21.5 F1000.0               ;continue line
G1 Y45
G92 E0             

;CONTINUE PRINT
;Put printing message on LCD screen
M117 Stampa...
@SPEAK La stampa e iniziata
; -- end of START GCODE --

tombrazier commented 2 years ago

@andreibobirica I have been looking into PLANAR, 3POINT and BILINEAR leveling. There are a number of things I am aware of. Some may apply more generally and so affect MESH leveling. Two questions:

Are you using skew correction? I think there is a bug with the order in which leveling and skew correction are applied that I have not yet raised as an issue.
Do you know that you can manually level with BILINEAR leveling instead of MESH? Just set PROBE_MANUALLY and use the G29 parameters for BILINEAR. (You can also probe manually with UBL - I think it's just an option in the G29 parameters but am not certain about that.) Anyway it would be worth knowing whether the behaviour you see is specific to MESH or applies more generally.

it first moves the Y axis and then extrudes beyond the Y axis.

Do you mean it moves Z and Y separately? This is normal. From memory, I think it might be to do with preventing head crashes on non-cartesian machines.

andreibobirica commented 2 years ago

in the image I have shown on the left side the Ideal behavior with the start gcode posted above, in the right part it is an approximation of the true behavior with the new firmware. in green the movement of the head, in blue the moments of extrusion. I wanted to highlight how the Y goes much further. in addition to this there is a problem with the Z axis. in the third movement it should be 0.2 but also reaches 10 MM.furthermore the leveling is invalid, the mesh bed legeling does not work properly and goes much lower than should be when printing, even by 1mm.

I do not use Skew corection and It Is not activated. I use mesh bed legeling , i font know if ghete Is the sane problem even with other legeling system.

I poster my problem because i think Is related to G29 GCODE. In fact in the start gcode e have a lots of G29.

tombrazier commented 2 years ago

This sounds like a different problem to the one I was raising. I suggest you raise an new BUG issue.

tombrazier commented 2 years ago

Actually I now notice you have a toolchange. Your issue could be related to #22942 or #23325 which are both about axes getting out of alignment on tool changes.

GJSchaller commented 2 years ago

Looking like I have the same issue - no matter what I do, my first layer is refusing to stick to the bed (not squished enough). Does not seem to be hardware, happens regardless of slicer. Changing the Z-Probe offset on the printer itself does not change anything. BTT SKR mini E3 v2, Marlin 2.0.9.3 and Bugfix (March 2022) as well.

tombrazier commented 2 years ago

Changing the Z-Probe offset on the printer itself does not change anything.

That surprises me. With a low (or negative) enough Z probe offset you should eventually get squished lines in the hardware is physically able to get the head down that far. This bug results in inconsistency - sometimes the lines are squished too much and sometimes not enough. Decreasing Z probe offset makes the lines oversquished more often.

GJSchaller commented 2 years ago

That surprises me. With a low (or negative) enough Z probe offset you should eventually get squished lines in the hardware is physically able to get the head down that far. This bug results in inconsistency - sometimes the lines are squished too much and sometimes not enough. Decreasing Z probe offset makes the lines oversquished more often.

I'll try to do some testing - I raised my bed a fair amount and the same results were still happening. It may also be a different bug... my purge line comes out fine, but the actual print isn't squished enough. Once I get some wiring fixed, I'll try to narrow it down more.

thinkyhead commented 2 years ago

Converting from mm to steps and then back from steps to mm as part of leveling enable/disable may introduce a small error, but it should be relatively insignificant.

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.
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.

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.

MarlinFirmware / Marlin