<p>So I've followed the wonderful tutorial <a href="https://www.reddit.com/r/anycubic/comments/y2waxu/tutorial_how_to_build_anycubic_marlin_source_code/" rel="nofollow noreferrer">here</a> and managed to modify the Anycubic firmware to include more mesh points to probe for (I've set it to have a 15x15 grid because I'm printing a large scale project on my Kobra Plus and the first layer has to be immaculate, which it isn't due to highly warped bed). It went through the 30 minute or so time needed for this auto bed levelling with this larger grid, and all seemed okay, but then before printing I decided to connect the printer to Pronterface and actually get values that it stored from this procedure with the <code>M420 V</code> command, and... disaster. Values on X and Y from 4<sup>th</sup> to 11<sup>th</sup> are mostly zero, with some displaying ridiculously large numbers (I get that I have a warped bed, but not that much, haha). Now I do know that Marlin supports up to 15x15 grids, and the EEPROM of the Kobra Plus clearly has space for that since the grid returned has all 225 values, but there seems an issue where they are stored in these &quot;slots&quot; improperly. Is there maybe something that I'm missing or something else besides the <code>#define GRID_MAX_POINTS_X</code> definition that also has to be modified/enabled when changing the grid size?</p>
<p>After printer restart <code>M420 V</code> returns &quot;mesh invalid.&quot; (quite obviously, I'd say)</p>
<p><a href="https://i.sstatic.net/xuNOb.png" rel="nofollow noreferrer" title="Grid printout right after probing"><img src="https://i.sstatic.net/xuNOb.png" alt="Grid printout right after probing" title="Grid printout right after probing" /></a></p>
<p>It looks like an issue with storage specifically. I used <code>G29</code> from pronterface and it returned realistic values all-round. It's when you send <code>M500</code> and then try to print the mesh with <code>M420 V</code>, then it returns these ridiculous values. Confirmed this with <code>M420 C</code>, then <code>M500</code> and <code>M420 V</code>.</p>
<p>Same thing: Normal values, sent to storage, ridiculous values pulled. After reboot of the printer, there seems to be no mesh data at all.</p>

CC BY-SA 4.0
2023-01-31T19:00:15.780Z
This would be excellent to post in the Marlin GitHub, they might know if there are issues with large grids, if not you found a bug! Note that [11, 3] has an "infinite" (or at least very large) number. This makes you wonder if these floats are missing the scientific exponent? E.g. is [0, 0] -2.165 E-02? It doesn't explain the large positive and negative numbers though...
0scar
CC BY-SA 4.0
2023-01-31T19:46:10.503Z
It looks like an issue with storage specifically. I used G29 from pronterface and it returned realistic values all-round. It's when you send M500 and then try to print the mesh with M420 V, then it returns these ridiculous values. Confirmed this with M420 C, then M500 and M420 V. Same thing: Normal values, sent to storage, ridiculous values pulled. After reboot of the printer, there seems to be no mesh data at all.
Eugene
CC BY-SA 4.0
2023-01-31T22:13:35.637Z
Hi Eugene and welcome. If you can, it *might* be a good idea to copy and paste the text from the log file into the post and format it using code formatting - rather than just a screenshot. This is because text in an image is not searchable, whereas pasted text is. Thanks.
Greenonline
CC BY-SA 4.0
2023-02-01T10:44:48.640Z
If it is an SKR board and an old Marlin version, storage of variables doesn't work. I can't remember from which version it works, but this could be the case. I wonder why this printer series is so special that normal Marlin doesn't work.
0scar
<marlin><bed-leveling><adhesion><pronterface>
15x15 mesh returns ridiculous values
Eugene
# 15x15 mesh returns ridiculous values

(Asked by: username_0 on 2023-01-31)

So I've followed the wonderful tutorial [here](https://www.reddit.com/r/anycubic/comments/y2waxu/tutorial_how_to_build_anycubic_marlin_source_code/) and managed to modify the Anycubic firmware to include more mesh points to probe for (I've set it to have a 15x15 grid because I'm printing a large scale project on my Kobra Plus and the first layer has to be immaculate, which it isn't due to highly warped bed). It went through the 30 minute or so time needed for this auto bed levelling with this larger grid, and all seemed okay, but then before printing I decided to connect the printer to Pronterface and actually get values that it stored from this procedure with the `M420 V` command, and... disaster. Values on X and Y from 4th to 11th are mostly zero, with some displaying ridiculously large numbers (I get that I have a warped bed, but not that much, haha). Now I do know that Marlin supports up to 15x15 grids, and the EEPROM of the Kobra Plus clearly has space for that since the grid returned has all 225 values, but there seems an issue where they are stored in these "slots" improperly. Is there maybe something that I'm missing or something else besides the `#define GRID_MAX_POINTS_X` definition that also has to be modified/enabled when changing the grid size?

After printer restart `M420 V` returns "mesh invalid." (quite obviously, I'd say)

[![Grid printout right after probing](https://i.sstatic.net/xuNOb.png "Grid printout right after probing")](https://i.sstatic.net/xuNOb.png "Grid printout right after probing")

It looks like an issue with storage specifically. I used `G29` from pronterface and it returned realistic values all-round. It's when you send `M500` and then try to print the mesh with `M420 V`, then it returns these ridiculous values. Confirmed this with `M420 C`, then `M500` and `M420 V`.

Same thing: Normal values, sent to storage, ridiculous values pulled. After reboot of the printer, there seems to be no mesh data at all.

**Tags:** marlin, bed-leveling, adhesion, pronterface

> **Comments:**
> **username_1**: This would be excellent to post in the Marlin GitHub, they might know if there are issues with large grids, if not you found a bug! Note that [11, 3] has an "infinite" (or at least very large) number. This makes you wonder if these floats are missing the scientific exponent? E.g. is [0, 0] -2.165 E-02? It doesn't explain the large positive and negative numbers though...  
> **username_0**: It looks like an issue with storage specifically. I used G29 from pronterface and it returned realistic values all-round. It's when you send M500 and then try to print the mesh with M420 V, then it returns these ridiculous values. Confirmed this with M420 C, then M500 and M420 V. Same thing: Normal values, sent to storage, ridiculous values pulled. After reboot of the printer, there seems to be no mesh data at all.  
> **username_2**: Hi username_0 and welcome. If you can, it *might* be a good idea to copy and paste the text from the log file into the post and format it using code formatting - rather than just a screenshot. This is because text in an image is not searchable, whereas pasted text is. Thanks.  
> **username_1**: If it is an SKR board and an old Marlin version, storage of variables doesn't work. I can't remember from which version it works, but this could be the case. I wonder why this printer series is so special that normal Marlin doesn't work.  

---

## 0 answers

