Mesh bed levelling does not update any more after MemoryError

Question

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?

Answer 1

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 2

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.