<p>I have formatted the SD card and installed Octoprint from scratch. That's nasty, because I lost all the models I uploaded.</p>
<p>It seems to be a bug in <a href="https://github.com/PrusaOwners/OctoPrint-PrusaMeshMap/blob/master/octoprint_PrusaMeshMap/__init__.py" rel="nofollow noreferrer">__init__.py</a> of OctoPrint-PrusaMeshMap (archived Github repository).</p>
<p>That code saves the heatmap in this line:</p>
<pre><code>fig.savefig(self.get_asset_folder() + '/img/heatmap.png', bbox_inches=&quot;tight&quot;)
</code></pre>
<p>It uses Pyplot</p>
<pre><code>import matplotlib.pyplot as plt
</code></pre>
<p>and thus the code should probably use (untested!)</p>
<pre><code>plt.close(fig) 
del fig
</code></pre>
<p>to free the resources.
Unfortunately it's not possible to file this as an issue because the Github repository is in archived mode and thus readonly.</p>

CC BY-SA 4.0
2020-10-12T10:58:42.283Z
2020-10-12T11:10:41.377Z
2020-10-12T11:10:41.377Z
Thomas Weller
<p>You have found a bug in the OctoPrint plugin. As you noticed, not more than 20 graphs can be created/open at a time. This implies that the developer has not implemented pyplot correctly, this is a common mistake that I have ran into myself once or twice. You should notify the developer.</p>
<p>The problem is that the old graph is not destroyed or not properly updated (I think it is intended to update the graph). The code passes the create plot multiple times and after 20 graphs it will drop the error message.</p>
<p>If you reset the Pi or reload the Octoprint server you are probably good to go for another 20 graphs.</p>

CC BY-SA 4.0
2020-10-12T06:22:53.607Z
2020-10-12T06:22:53.607Z
0scar
<p>I have had issues with printing on my i3 MK3, especially when it came to the first layer. In March 2020, I have installed the Prusa Mesh Leveling plugin for Octoprint. With that plugin and a Nylock nut modification, I was able to reduce the bed variance from 0.6 mm down to 0.014 mm and prints were great. That took about 25 rounds of calibration and I didn't have any issues with the graphics not updating.</p>
<p><a href="https://i.sstatic.net/Fo7Ag.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Fo7Ag.png" alt="Mesh bed levelling on March 2020" /></a></p>
<p>Shortly after that, my filament sensor stopped working and I ordered a replacement, which I installed yesterday. But today, my prints are bad again, especially the first layer. So I thought I would simply run through the calibration and mesh bed leveling again.</p>
<p>First, I turned the screws in the wrong direction, so the result became worse and I needed several attempts until the results went into the correct direction. I'm currently at ~1.0 mm bed variance, which is very bad and I need to continue leveling the bed.</p>
<p><a href="https://i.sstatic.net/lR588.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/lR588.png" alt="Bed variance currently" /></a></p>
<p>Now, the graphics does not update any longer. It always shows the same picture.</p>
<p>I also noticed some different behavior of the mesh bed levelling procedure. Usually, after running the mesh bed levelling, the printer needs some time (~5 secs) before it will react to other commands like a move on the Z axis. I used the following technique to find out when to reload the graphics:</p>
<ul>
<li>run mesh bed levelling</li>
<li>tell the printer to move up 10 mm on the Z axis</li>
<li>as soon as the print head moves up, it was possible to reload the graphics</li>
</ul>
<p>Now, the print head moves up immediately after the mesh bed levelling, without the ~5 secs delay and the graphics does not update.</p>
<p>I have already tried:</p>
<ul>
<li>click the &quot;reload heat map&quot; button</li>
<li>run mesh bed leveling again</li>
<li>restarting Octoprint</li>
<li>resetting the printer using the X button</li>
<li>looking for disk space via SSH</li>
</ul>
<p>.</p>
<pre><code>pi@octopi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.3G  1.9G  5.1G  27% /
devtmpfs        182M     0  182M   0% /dev
tmpfs           186M     0  186M   0% /dev/shm
tmpfs           186M  2.7M  183M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           186M     0  186M   0% /sys/fs/cgroup
/dev/mmcblk0p1   42M   21M   21M  51% /boot
tmpfs            38M     0   38M   0% /run/user/1000
</code></pre>
<p>In the log file (<code>octoprint.log</code>) with output level set to <code>DEBUG</code>, I could see an entry:</p>
<pre><code>2020-06-06 12:19:52,261 - octoprint.plugins.PrusaMeshMap - INFO - Generating heatmap
2020-06-06 12:19:52,288 - py.warnings - WARNING - 
    /home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/pyplot.py:522:
    RuntimeWarning: More than 20 figures have been opened. 
    Figures created through the pyplot interface (`matplotlib.pyplot.figure`) are
    retained until explicitly closed and may consume too much memory. 
    (To control this warning, see the rcParam `figure.max_open_warning`).
    max_open_warning, RuntimeWarning)
</code></pre>
<p>As you can see, this was at 12:19. The last graphics I saw is from 12:37.</p>
<p>The logs also contain a message on 12:40:</p>
<pre><code>2020-06-06 12:40:39,262 - octoprint.util.comm - ERROR - Error while processing hook PrusaMeshMap:
Traceback (most recent call last):

  File &quot;/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py&quot;, line 2849, in _readline
    ret = hook(self, ret)
  File &quot;/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_PrusaMeshMap/__init__.py&quot;, line 90, in mesh_level_check
    self.mesh_level_generate()
  File &quot;/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_PrusaMeshMap/__init__.py&quot;, line 236, in mesh_level_generate
    fig.savefig(self.get_asset_folder() + '/img/heatmap.png', bbox_inches=&quot;tight&quot;)
[...]
  File &quot;/home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/image.py&quot;, line 512, in _make_image
    output = self.to_rgba(output, bytes=True, norm=False)
  File &quot;/home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/cm.py&quot;, line 259, in to_rgba
    xx = (xx * 255).astype(np.uint8)
MemoryError
</code></pre>
<p>On 12:46 I rebooted the system</p>
<pre><code>2020-06-06 12:46:08,761 - octoprint.server.api.system - INFO - Performing command for core:reboot: sudo shutdown -r now
</code></pre>
<p>but of course that graphics is still missing and the last available graphics is the one from 12:37. So, after the reboot one needs to run the mesh bed leveling again.</p>
<p>Still, no luck...</p>
<p>OctoPrint version is 1.4.0, OctoPi version 0.15.0PE, Prusameshmap Plugin: 0.3.0. As far as I can tell, that's the latest version available.</p>
<p>What can I do to make mesh bed leveling work again?</p>

CC BY-SA 4.0
2020-10-12T06:24:02.110Z
Is this still a problem? I suspect this is a bug in the plugin. Note [this bug report](https://github.com/PrusaOwners/OctoPrint-PrusaMeshMap/issues/31), this is probably the same issue, but it has been closed!
0scar
CC BY-SA 4.0
2020-10-12T10:33:32.630Z
@0scar: it has been closed, but there's no code fix associated with it.
Thomas Weller
<prusa-i3><bed-leveling><octoprint>
Mesh bed levelling does not update any more after MemoryError
Thomas Weller
# Mesh bed levelling does not update any more after MemoryError

(Asked by: username_0 on 2020-06-06)

I have had issues with printing on my i3 MK3, especially when it came to the first layer. In March 2020, I have installed the Prusa Mesh Leveling plugin for Octoprint. With that plugin and a Nylock nut modification, I was able to reduce the bed variance from 0.6 mm down to 0.014 mm and prints were great. That took about 25 rounds of calibration and I didn't have any issues with the graphics not updating.

Shortly after that, my filament sensor stopped working and I ordered a replacement, which I installed yesterday. But today, my prints are bad again, especially the first layer. So I thought I would simply run through the calibration and mesh bed leveling again.
First, I turned the screws in the wrong direction, so the result became worse and I needed several attempts until the results went into the correct direction. I'm currently at ~1.0 mm bed variance, which is very bad and I need to continue leveling the bed.

Now, the graphics does not update any longer. It always shows the same picture.
I also noticed some different behavior of the mesh bed levelling procedure. Usually, after running the mesh bed levelling, the printer needs some time (~5 secs) before it will react to other commands like a move on the Z axis. I used the following technique to find out when to reload the graphics:

run mesh bed levelling
tell the printer to move up 10 mm on the Z axis
as soon as the print head moves up, it was possible to reload the graphics

Now, the print head moves up immediately after the mesh bed levelling, without the ~5 secs delay and the graphics does not update.
I have already tried:

click the "reload heat map" button
run mesh bed leveling again
restarting Octoprint
resetting the printer using the X button
looking for disk space via SSH

.
pi@octopi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.3G  1.9G  5.1G  27% /
devtmpfs        182M     0  182M   0% /dev
tmpfs           186M     0  186M   0% /dev/shm
tmpfs           186M  2.7M  183M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           186M     0  186M   0% /sys/fs/cgroup
/dev/mmcblk0p1   42M   21M   21M  51% /boot
tmpfs            38M     0   38M   0% /run/user/1000

In the log file (octoprint.log) with output level set to DEBUG, I could see an entry:
2020-06-06 12:19:52,261 - octoprint.plugins.PrusaMeshMap - INFO - Generating heatmap
2020-06-06 12:19:52,288 - py.warnings - WARNING - 
    /home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/pyplot.py:522:
    RuntimeWarning: More than 20 figures have been opened. 
    Figures created through the pyplot interface (`matplotlib.pyplot.figure`) are
    retained until explicitly closed and may consume too much memory. 
    (To control this warning, see the rcParam `figure.max_open_warning`).
    max_open_warning, RuntimeWarning)

As you can see, this was at 12:19. The last graphics I saw is from 12:37.
The logs also contain a message on 12:40:
2020-06-06 12:40:39,262 - octoprint.util.comm - ERROR - Error while processing hook PrusaMeshMap:
Traceback (most recent call last):

  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2849, in _readline
    ret = hook(self, ret)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_PrusaMeshMap/__init__.py", line 90, in mesh_level_check
    self.mesh_level_generate()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_PrusaMeshMap/__init__.py", line 236, in mesh_level_generate
    fig.savefig(self.get_asset_folder() + '/img/heatmap.png', bbox_inches="tight")
[...]
  File "/home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/image.py", line 512, in _make_image
    output = self.to_rgba(output, bytes=True, norm=False)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/matplotlib/cm.py", line 259, in to_rgba
    xx = (xx * 255).astype(np.uint8)
MemoryError

On 12:46 I rebooted the system
2020-06-06 12:46:08,761 - octoprint.server.api.system - INFO - Performing command for core:reboot: sudo shutdown -r now

but of course that graphics is still missing and the last available graphics is the one from 12:37. So, after the reboot one needs to run the mesh bed leveling again.
Still, no luck...
OctoPrint version is 1.4.0, OctoPi version 0.15.0PE, Prusameshmap Plugin: 0.3.0. As far as I can tell, that's the latest version available.
What can I do to make mesh bed leveling work again?

**Tags:** prusa-i3, bed-leveling, octoprint
> **Comments:**
> **username_1**: Is this still a problem? I suspect this is a bug in the plugin. Note [this bug report](https://github.com/PrusaOwners/OctoPrint-PrusaMeshMap/issues/31), this is probably the same issue, but it has been closed!  
> **username_0**: @0scar: it has been closed, but there's no code fix associated with it.  

---

## 2 answers

### Answer by username_0 on 2020-10-12. Score: 1 | Accepted answer

I have formatted the SD card and installed Octoprint from scratch. That's nasty, because I lost all the models I uploaded.
It seems to be a bug in __init__.py of OctoPrint-PrusaMeshMap (archived Github repository).
That code saves the heatmap in this line:
fig.savefig(self.get_asset_folder() + '/img/heatmap.png', bbox_inches="tight")

It uses Pyplot
import matplotlib.pyplot as plt

and thus the code should probably use (untested!)
plt.close(fig) 
del fig

to free the resources.
Unfortunately it's not possible to file this as an issue because the Github repository is in archived mode and thus readonly.


---

### Answer by username_1 on 2020-10-12. Score: 0

You have found a bug in the OctoPrint plugin. As you noticed, not more than 20 graphs can be created/open at a time. This implies that the developer has not implemented pyplot correctly, this is a common mistake that I have ran into myself once or twice. You should notify the developer.

The problem is that the old graph is not destroyed or not properly updated (I think it is intended to update the graph). The code passes the create plot multiple times and after 20 graphs it will drop the error message.

If you reset the Pi or reload the Octoprint server you are probably good to go for another 20 graphs.


---

