[FR] Save UBL Mesh data to SD

[moccor]

Is your feature request related to a problem? Please describe.

I am using a custom build of Marlin for the Geeetech A30T from here - https://github.com/TheThomasD/GeeetechA30T - and for some reason it won't save mesh to EEPROM like it should work and does work for others using the same build. I have tried many different settings in the Marlin configuration.h and none of them allowed saving to EEPROM to work, so I am asking here if it is possible to somehow save UBL Mesh to SD.

Some things I remember and have tried :

• defined SD support
• defined EEPROM_SETTINGS
• G29 A, G29 S, G29 S1, G29 L, G29 L1, M420 S, M420 L, M500, etc

I feel like I have tried literally everything and looked through the entire code to figure out how to make things work, but saving to EEPROM just won't work even though it is known to just work from flashing with that custom A30T build. So I am wondering if it is possible to add a save mesh to SD feature, that can then be loaded via gcode, so I can make use of something like a 15x15 mesh without waiting 40 minutes before each print, since my A30T glass bed seems to be warped unfortunately.

Are you looking for hardware support?

No response

Describe the feature you want

I want to be able to do a large UBL mesh like 10x10 or so and save it to SD to be able to re-load the mesh after printer power downs since my EEPROM doesn't seem to save mesh data thru a power off, no matter what I do.

Or is there some alternative to where I can retrieve the data in some way, and then create a gcode file of it to load on each printer start before printing? Thanks for any thoughts

Additional context

No response

[Bob-the-Kuhn]

Something is broken if the UBL mesh isn't being restored automatically. At least I'd expect to see en EEPROM CRC error being thrown up when you do an M503.

M420 V3 will display the mesh and tell you what EEPROM slot it was loaded from. Maybe it's using a different slot than what you stored to.

To use the SD card to emulate EEPROM add the following line to configuration.h: #define SDCARD_EEPROM_EMULATION

You may need to comment out #define FLASH_EEPROM_EMULATION in Marlin/src/pins/stm32f1/pins_GTM32_103_V1.h

[moccor]

Oh wow I was looking for a setting like that and couldn't find it, I guess since it was text that needed to be added. I would try multiple G29 S1, G29 S2, G29 S3, etc and try loading them but they would all be empty after a power off + on.

I am giving it a try now. Is it normal for terminal to say this when saving with M500 or is there a different way to save with SD? : Send: M500 Recv: echo:No EEPROM. Recv: ok

Edit: So I tried it, didn't seem to work out. It wouldn't save the home offset nor would it save the mesh. I went and reversed the comment out and adding of SD EEPROM EMULATION, and it saves the home offset like normal, but ofc also won't save mesh.

Thanks for the help and any thoughts

[borland1]

You can set/change individual mesh points with g-code ( e.g., M421 I2 J2 Z-0.05 ). So, with the mesh report ( G29 S0 ), I don't see why you couldn't create g-code print file(s) to load the entire mesh.

[moccor]

The only time I ever saw the terminal show that info, was when I enabled #define SDCARD_EEPROM_EMULATION and did a G29 S, it showed that info. But if I disable #define SDCARD_EEPROM_EMULATION, it never shows that info or I don't know how to show it.

Also I noticed something. When not using #define SDCARD_EEPROM_EMULATION, doing a G29 P1 and saving with M500, it says it saves as it always has. Then I shut off the printer and the numbers are gone like it always has. The different thing I noticed is, it does "save" a mesh, but it only saves 0.000 everywhere in the mesh. The difference is when I do M420 L30 or any of the numbers I never touched, it shows dots everywhere.

Why would it save a bunch of zero's but not save the actual numbers I need?

[borland1]

I don't know, could be hardware or user configuration errors. Firmware bugs are is less likely cause of this problem unless several others having reported the same issues.

Have you tried using Bilinear Bed Leveling instead of UBL The G-code options are different, depending on the type of bed leveling you have selected ( Linear, Manual, Bilinear, Unified ).

I like the FR request for saving the mesh to SD-card file since I only use Manual Bed Leveling, so I rarely adjust the mesh. But that assumes I have the bed corners such that the bed springs are evenly compressed. Without this, any changes in bed temperature ( like when switching between PLA to PETG ), will affect the mesh settings as the bed deflection due to uneven spring loads will change with temperature.

[thinkyhead]

In the meantime, save leveling data to SD by copying the output of M503 to a file with a .gcode extension and remove the settings that you don't want to override. If the file is called auto0.g it will load at boot up.

[moccor]

I don't know, could be hardware or user configuration errors. Firmware bugs are is less likely cause of this problem unless several others having reported the same issues.

Have you tried using Bilinear Bed Leveling instead of UBL The G-code options are different, depending on the type of bed leveling you have selected ( Linear, Manual, Bilinear, Unified ).

I like the FR request for saving the mesh to SD-card file since I only use Manual Bed Leveling, so I rarely adjust the mesh. But that assumes I have the bed corners such that the bed springs are evenly compressed. Without this, any changes in bed temperature ( like when switching between PLA to PETG ), will affect the mesh settings as the bed deflection due to uneven spring loads will change with temperature.

I think it is something to do with the EEPROM, whether it is faulty or whether it has the same problem as some recent Creality with smaller EEPROM I saw when researching (I think normally its 512 but recently it was 256 and needed a new Marlin build?). But I tried everything I could possible find, however the FW created by TheThomasD simply works fine from flash with no changes for others. I have not tried using any other forms of bed leveling, however after reading about the differences between UBL and Bilinear, I def need to give Bilinear a try and see if it saves thru a power off.

In the meantime, save leveling data to SD by copying the output of M503 to a file with a .gcode extension and remove the settings that you don't want to override. If the file is called auto0.g it will load at boot up.

Does M503 normally output all of the leveling code? I think the many times I have done it, I didn't see any leveling code, even before a shutdown. However I know I sometimes saw extra info when enabling #define SDCARD_EEPROM_EMULATION , so I guess I will give that a try as well and see how it works. I also was not aware about the 'auto0.g', that is great to know.

Edit: So I did a test with Bilinear leveling, and it persisted in EEPROM thru a shutdown, as well as showed me the info I needed in M503. Is there anything that makes sense as to why it would work with Bilinear but not with UBL? I enabled and disabled it in the same ways. Could it be my MESH_INSET for UBL that I set to 30 due to having clips on the bed? I mean that doesn't make sense but it might be the only single variable possible at this point 🤔.

Edit 2: It seems like the bilinear, though it saves, it always is about 3-4mm too high when printing even if I lower the Z in the slicer. I always keep it around a specific number in the sliver and FW and never touch it, but something about the Bilinear makes it be much higher