Bed Mesh data no longer accessible

Basic Information:

Anycubic Mega Zero 2
ATmega1284p & R-pi4B V1.4 w/4GB
Klipper: v0.11.0-41-g9b60daf6
Octoprint 1.8.6
Python 3.7.3
Octopi 0.18.0
Superslicer 2.4.58.5
klippy.log (538.6 KB)

Describe your issue:

Manual Bed Mesh is no longer accessible. Discovered FADE was causing me print grief and along the way noticed that the BED MESH was no longer retrievable. Klippy says;

Can’t read autosave from config file - autosave state corrupted.

Troubleshooting:

Cleared the existing data with BED_MESH_CLEAR then ran the manual BED_MESH_CALIBRATE. All normal including viewing the output results via BED_MESH_OUTPUT and SAVE_CONFIG. Also, the Bed Visualizer plugin can read the mesh data immediately following the tramming procedure and prior to SAVE_CONFIG. After restarting via SAVE_CONFIG, BED_MESH_PROFILE LOAD=default errs with

!! bed_mesh: Unknown profile [default].

Have cleared and re-run the mesh routine several times. Error results are consistent - Klippy error, can’t load manually via Terminal, and not accessible via Bed Visualizer. Printer.cfg file read/write is otherwise normal even the BED MESH config data appears there.

Terminal:
Recv: // Mesh Bed Leveling Complete
Recv: // Bed Mesh state has been saved to profile [default]
Recv: // for the current session. The SAVE_CONFIG command will
Recv: // update the printer config file and restart the printer.
Recv: ok
[…]
Send: bed_mesh_output
Recv: // Mesh Leveling Probed Z positions:
Recv: // 0.000000 0.025000 0.025000
Recv: // 0.025000 0.025000 0.000000
Recv: // 0.025000 0.062500 0.025000
Recv: Mesh X,Y: 7,7
Recv: Search Height: 5
Recv: Mesh Offsets: X=0.0000, Y=0.0000
Recv: Mesh Average: 0.03
Recv: Mesh Range: min=0.0000 max=0.0625
Recv: Interpolation Algorithm: lagrange
Recv: Measured points:
Recv: 0.025000 0.045833 0.058333 0.062500 0.058333 0.045833 0.025000
Recv: 0.027778 0.039660 0.045679 0.045833 0.040123 0.028549 0.011111
Recv: 0.027778 0.033642 0.035494 0.033333 0.027160 0.016975 0.002778
Recv: 0.025000 0.027778 0.027778 0.025000 0.019444 0.011111 0.000000
Recv: 0.019444 0.022068 0.022531 0.020833 0.016975 0.010957 0.002778
Recv: 0.011111 0.016512 0.019753 0.020833 0.019753 0.016512 0.011111
Recv: 0.000000 0.011111 0.019444 0.025000 0.027778 0.027778 0.025000
Recv:
Recv: ok
[…]
Send: SAVE_CONFIG
Recv: ok
Recv: // Klipper state: Disconnect
[…]
Recv: // Klipper state: Ready
[…]
Send: bed_mesh_output
Recv: // Bed has not been probed
Recv: ok
[…]
Send: bed_mesh_profile load=default
Recv: !! bed_mesh: Unknown profile [default]
Recv: ok

Is there a syntax tutorial for the printer.cfg file editor? I searched but did not find one.

Reason is I had borrowed the #*# that is used to prepend Autosave content and use it to create other header sections of the config file simply because doing so causes the text to show up brightly in the editor and is thus easier to notice.

Well, apparently that’s not kosher and was the root cause of the subject issue that generated the autosave state corrupted error that I’d described above. Removing any occurrence of #*# except from the Autosave area relieved the corruption issue and Klipper was able to read the config file without error.

FYI

#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.

Should be enough to indicate not to mess around with the following syntax, don’t you agree?

To be fair, I think most people would assume that means you simply shouldn’t touch anything below the “SAVE_CONFIG” line. I don’t think it necessarily communicates that you can’t use the #*# sequence above that line.

Oh well, of course there is always room for improvement. But honestly, where do you want to start and where to end? Hardly anyone is even reading the existing documentation

It is such an incredibly good documentation. Please guys, it is worth reading it! We are talking about open-source here!

“Klipper is open-source software and we appreciate new contributions.” Contact - Klipper documentation Well…

:grin:
So, are you suggesting to not improve documentation because of the assertion that ‘no one is reading’ it? C’monnnnn!

Just kidding. The time that you have and continue to invest in fielding mine and other’s questions here can’t be over-stated. THANK YOU! Thus, your assertion is indeed grounded in truth.

2 Likes