Leveling doesn't save to EEPROM

[PetrKozanek]

Hello I have Kossel Linear Plus with SKR 1.3 board and Marlin 2.0.5.3 I'm using linear leveling. After leveling is done, I use M500 to save, but leveling doesn´t save to EEPROM.

Thank you

[Tannoo]

FDI: UBL data saving works fine.

[Tannoo]

Can you post your config files?

[PetrKozanek]

Configuration.zip

[PetrKozanek]

I´m found out, that leveling was probably saved, but matrix has error, for example: +1.000000 +0.000000 -0.000094 -0.000000 +1.000000 -0.000071 +0.000094 +0.000071 +1.000000

[Tannoo]

that leveling data is really good.

Now, are those numbers the same after a power cycle?

[PetrKozanek]

power cycle is what?

[Tannoo]

Turning off the printer and turning it back on after ~ 10 seconds.

[sjasonsmith]

@PetrKozanek I just verified that I can save my Bilinear data on an SKR 1.3, using the latest bugfix-2.0.x from today.

Have you been able to verify whether it is working for you? Right now it seems like this issue should probably be closed.

[PetrKozanek]

@sjasonsmith

Bilinear leveling working fine, but linear leveling doesnť work.

[sjasonsmith]

@PetrKozanek I see a similar "corrupted" mesh when I switch to Linear. It probed a 5x5 grid, yet this is what M420 reports:

Send: M420 V
Recv: Bed Level Correction Matrix:
Recv: +0.999900 +0.000000 +0.014107
Recv: -0.000022 +0.999999 +0.001540
Recv: -0.014107 -0.001540 +0.999899

For comparison, this is the bed when probed with a BILINEAR 5x5 enabled. I have the bed intentionally skewed to I can be sure whether leveling is working.

I think the issue is only in how it is being reported though. For starters, this is reporting 9 points even though I probed 25. I also manually jogged across the bed with leveling enabled, and it followed the bed properly, not as the visualizer displayed.

[sjasonsmith]

I believe this is working as expected, we are just incorrectly assuming that M420 V will produce output from M420 V that actually looks like the bed shape you get from BILINEAR.

The key note from the M420 documentation is: [V<bool>] | Verbose: Print the stored mesh / matrix data

When using LINEAR leveling, it doesn't actually store the probed points. It stores a 3x3 matrix which is used to define the correction, so you can't actually retrieve the probed points themselves.

You can see below that by running G29 T you can see a topography report at the end of the probing cycle, and that reflects my actual bed shape. The G29 code as to do some processing on the data to generate that report. In this case I probed just a 3x3 grid, I'm not sure what the report looks like had I probed with 5x5.

Send: G29 T
[...]
Recv: Bed Height Topography:
Recv:    +--- BACK --+
Recv:    |           |
Recv:  L |    (+)    | R
Recv:  E |           | I
Recv:  F | (-) N (+) | G
Recv:  T |           | H
Recv:    |    (-)    | T
Recv:    |           |
Recv:    O-- FRONT --+
Recv:  (0,0)
Recv:  -1.03167 +0.12833 +1.51583
Recv:  -1.28167 -0.18167 +1.26083
Recv:  -1.26417 -0.24917 +1.10333
[...]
Send: M420 V
Recv: Bed Level Correction Matrix:
Recv: +0.999901 +0.000000 +0.014043
Recv: -0.000022 +0.999999 +0.001585
Recv: -0.014043 -0.001585 +0.999900
Recv: echo:Bed Leveling ON
Recv: ok

[sjasonsmith]

I just started a print covering most of the bed using that stored correction matrix, and it is looking pretty good. Not absolutely perfect, but my bed is also not perfectly flat, so LINEAR correction isn't ideal for it.

[boelle]

@PetrKozanek still an issue?

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[github-actions[bot]]

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.