[BUG] Bilinear Leveling - Implausible results when using different numbers for X/Y grid points

[parallyze]

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

Yes, and the problem still exists.

Bug Description

Hi,

somehow I didn't notice this before, but there seems to be a problem using Bilinear Levelling and
certain values for x/y grid points.

While everything works as expected when using 5x5 points, this is what was happening on one of
my printers running 2.1 release:

initial power on, followed by G28 and G29

READ:       0      1      2      3      4
READ:  0 -0.023 -0.011 +0.013 -0.079 +0.000
READ:  1 -0.002 +0.007 -0.056 -0.104 +0.000
READ:  2 +0.003 -0.039 -0.086 -0.049 +0.000
READ:  3 -0.003 -0.072 -0.010 -0.022 +0.000

Note the 5th point along the X axis reporting all 0.

Another G29 right after that (another G28 doesn't affect this in any way) returns:

READ:       0      1      2      3      4
READ:  0 -0.021 -0.007 +0.018 -0.074 +0.015
READ:  1 -0.006 +0.026 -0.045 -0.071 -0.077
READ:  2 +0.024 -0.029 -0.081 -0.037 -0.112
READ:  3 +0.003 -0.058 +0.003 -0.023 -0.041

I've tested this numerous times - each time after a power cycle the first G29 does
return 0 for each 5th point along X.

The bed in that printer is ~210x150mm, that's why I've chosen 5x4.

I did test this on the same machine using the same config files on bugfix-2.1.x, it's
the same behavior.

This also happens with 2.0.9.3, which was running before on that machine (although
I was using UBL and didn't notice something like this before). 2.0.8 does not show these
implausible values.

I then tested this on a completely different printer running Marlin 2.0.9.3. It's a DIY
i3 clone using Bilinear Levelling with a 5x5 grid on a 300mm x 300mm bed. This machine
didn't show the strange behavior - unless I compiled the firmware using 5x4 points. And
here's the output from G29 after a power cycle on that machine:

READ:       0      1      2      3      4
READ:  0 +0.085 -0.018 -0.003 +0.137 +0.000
READ:  1 +0.105 +0.010 +0.062 -0.125 +0.000
READ:  2 +0.107 +0.015 -0.173 +0.137 +0.000
READ:  3 +0.127 -0.155 +0.032 +0.147 +0.000

Another G29:

READ:       0      1      2      3      4
READ:  0 +0.085 -0.013 -0.003 +0.130 +0.103
READ:  1 +0.110 +0.005 +0.062 -0.123 +0.130
READ:  2 +0.102 +0.010 -0.170 +0.142 +0.097
READ:  3 +0.127 -0.148 +0.032 +0.142 +0.092

Same thing happening.

Edit:
That one is running a SKR2 + TMC2208 + BLTouch clone, not a MKS SGEN L like the other one also showing the problem.

Yelling "BUG!" is easy - but maybe I've just completely overseen something? I haven't seen
any comments about not using different numbers of grid points along X/Y, so maybe I've
just messed up here? ^^

bugfix-2.1.x-configs for the replicator-style machine attached. Pin file is included because
the rotary encoder isn't connected to the default pins.

I've tried various things while testing, setting Z speeds much lower, disabling HS mode for
the BLtouch - doesn't change the outcome, at least for me.

M48 didn't show any problems:

SENT: M48 P20
READ: X:77.50 Y:74.00 Z:6.18 E:0.00 Count X:15500 Y:14800 Z:4944
READ: ok
READ: M48 Z-Probe Repeatability Test
READ: Finished!
READ: Mean: 0.005113 Min: -0.003 Max: 0.014 Range: 0.017
READ: Standard Deviation: 0.004574
READ: X:77.50 Y:74.00 Z:6.18 E:0.00 Count X:15500 Y:14800 Z:4944

Maybe anybody can reproduce this error. If there's any other logs/tests needed, let me know!

Thanks,
Daniel

Bug Timeline

Likely somewhere between 2.0.8 and 2.0.9.3, can't give a more precise answer right now

Expected behavior

I'd expect G29 to return somewhat similar values (within the probes capabilites) right after a power cycle, not
on the 2nd run.

Actual behavior

1st run of G29 when number of grid points is set to 5/4 returns 0 for every 5th point along X

Steps to Reproduce

1. Enable AUTO_BED_LEVELING_BILINEAR
2. GRID_MAX_POINTS_X 5
3. GRID_MAX_POINTS_Y 4
4. Power cycle machine
5. Execute G28 / G29, check results

Version of Marlin Firmware

2.0.9.3, 2.1 release & bugfix-2.1.x

Printer model

Custom, Replicator style (used to be a Malyan M180)

Electronics

MKS SGEN L, TMC2208, RepRap Full Graphics Controller

Add-ons

BLTouch Clone

Bed Leveling

ABL Bilinear mesh

Your Slicer

Simplify3D

Host Software

Same as my slicer

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

bugfix-21x_configs.zip

[parallyze]

Did some further testing. This seems to happen whenever GRID_MAX_POINTS_Y < GRID_MAX_POINTS_X. Everytime
after a power cycle the first G29 will return some 0 values - there seems to be a connection to the difference between above values.

X/Y set to 6/6: ( Y == X )

READ:       0      1      2      3      4      5
READ:  0 -0.015 -0.064 -0.080 -0.104 -0.121 -0.117
READ:  1 +0.006 -0.016 -0.021 -0.044 -0.015 -0.079
READ:  2 +0.009 +0.013 +0.115 -0.003 -0.021 -0.042
READ:  3 -0.002 -0.001 +0.007 -0.014 -0.041 -0.046
READ:  4 +0.001 -0.008 -0.010 -0.035 +0.176 -0.039
READ:  5 -0.009 -0.043 -0.059 -0.079 -0.100 -0.083

X/Y set to 5/6: ( Y > X )

READ:       0      1      2      3      4
READ:  0 +0.002 -0.028 -0.011 -0.001 +0.060
READ:  1 -0.006 -0.039 -0.071 -0.004 -0.014
READ:  2 +0.013 -0.035 -0.048 -0.064 +0.122
READ:  3 -0.006 +0.002 -0.014 -0.064 -0.095
READ:  4 -0.014 +0.006 +0.010 -0.049 -0.033
READ:  5 -0.028 -0.011 -0.001 +0.060 -0.025

X/Y set to 5/3: ( Y < X )

READ:       0      1      2      3      4
READ:  0 -0.025 -0.079 -0.019 +0.000 +0.000
READ:  1 -0.016 -0.084 -0.106 +0.000 +0.000
READ:  2 -0.036 +0.002 -0.071 +0.000 +0.000

Now there's two 0 values in each row (X - Y = 2?)....

[phizev]

@parallyze I had this issue arise on 2.0.9.3. Another issue I had arise which was seemingly related, was that the printer would just not even try to probe the last column. I had this occur with both bilinear, and UBL if I recall correctly. (Different builds, and I ignored the issue as I was focused on other bits of my printer. I can't provide more info as my printer is undergoing a partial rebuild/design.)

All of the above only happened when Y < X (My bed is square, though at the time I was limited in Y travel. DIY bed slinger, with RAMPS, and an inductive bed sensor.)

[Roxy-3D]

"Another issue I had arise which was seemingly related, was that the printer would just not even try to probe the last column. I had this occur with both bilinear, and UBL if I recall correctly. "

How far is your Z-Probe offset from the extruder? There will always be some portion of the bed that the nozzle can reach but the Z-Probe can't get to it. That is why the INSET numbers are available. It allows you to shrink the probable area of the bed. And it is also why G29 P3 exists in UBL. And lastly, G26 gives you the ability to see how far those unprobed points are off and you can edit them to what they should be.

[parallyze]

@parallyze I had this issue arise on 2.0.9.3. Another issue I had arise which was seemingly related, was that the printer would just not even try to probe the last column. I had this occur with both bilinear, and UBL if I recall correctly. (Different builds, and I ignored the issue as I was focused on other bits of my printer. I can't provide more info as my printer is undergoing a partial rebuild/design.)

All of the above only happened when Y < X

I remember seeing something like that when I swapped the extruder on one of the printers mentioned. It was using UBL
at that time. I had to limit X_MIN_POS by a few millimeters to avoid hitting the frame when probing after the change, this
was exactly when UBL started to only probe 20 of the configured 25 points, always skipping the left most probe points (X Min).
It would still display probing xx / 25 but stop probing after 20/25 and simply continue with the print job. I'm not sure this is related to the problem with 0s reporting, because this was when using a 5x5 grid on UBL and it would make sense looking at this:

That is why the INSET numbers are available. It allows you to shrink the probable area of the bed. And it is also why G29 P3 exists in UBL. And lastly, G26 gives you the ability to see how far those unprobed points are off and you can edit them to what they should be.

But I absolutely did not look into this any further - it happened right after the change of X_MIN_POS and I was in
the process of upgrading to 2.0.9.x (later 2.1) / ABL anyways. Now the print area is reduced a bit along X to compensate for
the loss when changing extruders - I like the probe being able to reach the whole print area... :)

I have also not tested if UBL does report any 0s on the first run if configured with points Y < X, only ABL_BILINEAR. But
if the results would be useful I can try and do that...

[Roxy-3D]

"I had to limit X_MIN_POS by a few millimeters to avoid hitting the frame when probing after the change, this
was exactly when UBL started to only probe 20 of the configured 25 points, always skipping the left most probe points (X Min)."

Most likely your probe was offset enough from the extruder that it wasn't possible to probe that row or column of the mesh. Depending on how you want to handle the problem, you can use the MESH_INSET values to address the problem. Or you can use G29 P3 to fill in the values with good guesses. And lastly, G26 is available to check your mesh and combined with G29 P4 you can edit any mesh point that is out of tolerance.

[parallyze]

Most likely your probe was offset enough from the extruder that it wasn't possible to probe that row or column of the mesh. Depending on how you want to handle the problem, you can use the MESH_INSET values to address the problem. Or you can use G29 P3 to fill in the values with good guesses. And lastly, G26 is available to check your mesh and combined with G29 P4 you can edit any mesh point that is out of tolerance.

Uhm... thanks. But I already quoted your previous post as a likely explanation why I think it's not an "error" I've seen there nor related to the 0s problem initially reported. My solution was to reduce the print area to compensate, as mentioned... and because I switched to ABL while upgrading (for completely different reasons) G29 P4/P5 wouldn't be available as I understand from the documentation...?

Sorry, I'm a bit confused now... ^^

[Roxy-3D]

I apologize. I lost track of who was saying what.

Thank you for your help!!!!

[tombrazier]

Thanks for reporting so clearly. Easily reproduced.

The problem is in a change from #23868 to the print_2d_array() function. The actual bed levelling info is right, but it isn't being printed out correctly.

[tombrazier]

Incidentally the issue occur when X != Y but is more obvious when X > Y. Note in the X/Y set to 5/6 case there are duplicate values - the bottom of each column is repeated in the top of the next.

[thisiskeithb]

Fixed in #24536

[github-actions]

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.