[BFW-5023] [BUG] Out of memory error when using prusa link | prusa link might affect print quality

[Fliens]

Printer type - [MINI]

Printer firmware version - 4.4.0 Beta 2

Original or Custom firmware - Original

Optional upgrades - [e.g. Filament Runout Sensor]

USB drive or USB/Octoprint USB

Describe the bug My printer ran out of memory for the first time. It happened when i started a print and was loading prusalink multiple times (refreshing the page).

I think prusa link affects print quality.

I need to do some more testing but it appears that prusa link takes some processing power that is needed to print. So the print thread needs to wait a bit which creates some thicker lines in the print. (especially noticeable on the z axis)

How to reproduce Please describe steps to reproduce the behavior.

Expected behavior A clear and concise description of what you expected to happen.

[darraghbr]

I got this same issue when I tried to start a print from the web UI, the printer just started alarming and I got that screen.

[Prusa-Support]

Hello! Thank you for your reports. Did it occur only with the attempts on printing with Prusa Link? Without it, would it work normally? How many prints did it take to error out (since last reboot)? How long was the printer on, and how long online? Would it occur with some specific GCodes, or anything, including simple printing tests?

Let me know, we'll look into it in more depth.

Alessandro Pantaleo Prusa Research

[darraghbr]

It only happened with me once, after I had done 3 or 4 prints with the printer being left on for 48 hours or so. The g-code worked fine after a reboot.

[jkavalik]

I had one case too when testing wifi and PrusaLink for the first time - the entire thing was very unresponsive and I probably did multiple browser tab refreshes too and got oomem error. Everything became much smoother when I removed the many files stored in the root of my flashdrive (moved them to a subdirectory actually as prusalink seems to entirely ignore them for now). I guess loading the gcode metadata (the "files" tab and maybe in the background) was really slowing the things down, but that was the reason of many page reloads in my case, not sure if the oom stems from the reloads or the number of files.

[jkavalik]

Ok, I just got another instance, 15min before the end of 4.5h print 🤦‍♂️ (my mistake though, should just have waited before testing things on BETA :D )

• I closed the PrusaLink tab by mistake, so I opened it again, had to login again with the api key and I got the dashboard with actual print progress - so far so good
• then I switched to the "Storage" tab and after maybe a second, maybe 3 the printer started beeping with a red oom message
• when I returned to the pc and tab opened, a single thumbnail was loaded (the second-oldest file surprisingly) and the rest were still questionmarks, after reload (printer not printing after the reset) everything loaded fine (6 files on the drive)
• the printer was about ~25h from the previous case and restart, about half of that total printing 5 jobs

So this time it was not a bing number of files on the drive and it was not many refreshes in a short time, the file being printed at the time is about 15MB gcode.

[Fliens]

Hello! Thank you for your reports. Did it occur only with the attempts on printing with Prusa Link? Without it, would it work normally? How many prints did it take to error out (since last reboot)? How long was the printer on, and how long online? Would it occur with some specific GCodes, or anything, including simple printing tests?

Let me know, we'll look into it in more depth.

Alessandro Pantaleo Prusa Research

Hi I can't answer these questions for the previous occurance but I just had the issue again.

When opening prusalink, I had to input my key again. After that I switched to the storage tab and started to scroll down. After 3 seconds I heard the prusa mini screaming in the basement and it was out of memory again. The mini was not doing anything, I had only opened prusa link.

[SpeakingOfBrad]

I just ran into this issue. I had uploaded a gcode from PrusaSlicer but got a 409 error so I went to the home screen on the printer, and then went to the storage tab on PrusaLink to find the uploaded file to print. PrusaLink was being a bit sluggish while scrolling through the files and was still trying to load thumbnails when I clicked print. Then I got the red screen that said "out of memory" with a loud long beep. Restarted and everything is working fine now.

Here is my crash dump. (At least I'm pretty sure this is the right crash dump. It seems all files uploaded to the USB from PrusaLink are dated December 31, 2097. I did have a dump.bin on the USB already, but I assume the printer overwrote it (no way to tell with the weird dates).) out-of-memory-dump.zip

[Prusa-Support]

Hello everyone! Thank you very much for providing these details, I passed on the info to our devs, we'll look into it in more depth. If anyone else is experiencing the same issue, or in case of any more details to add, do not hesitate to comment below.

Alessandro Pantaleo Prusa Research

[Prusa-Support]

Hello! After a review of this, we found it should be due to one of these 2 possible causes:

1. It might happen when the browser is closed accidentally - in that case, the solution would be logging in again in Prusa Link and clicking on "storage"
2. It might happen when the webpage is refreshing a few times "at a fast rate", like refreshing "a few times in a row".

Can you please review these possible aspects? Have you found the cause could have been one of these two, or anything different? Thank you for any feedback!

Alessandro Pantaleo Prusa Research

[Fliens]

Just had the issue again but this time I was uploading a file while the printer was printing.

Gcode Files

[Prusa-Support]

Hello! Thank you for your report on this, noted it so that we'll take a closer look in more depth on this cause with our devs.

Alessandro Pantaleo Prusa Research

[Pitel]

I got OOM error even when Interface is set to Off! Only to find later, that it does not actually disable anything, and my printer is still accessible via Wi-Fi. Another bug?

Anyway, because I thought it was disabled, I was not using it from browser or slicer. But, In my in-house IoT setup, I'm querying the printer temperatures and state every 5 minutes. So this might be the cause of random OOM errors I'm getting.

[Prusa-Support]

Hello! Thank you for your report. I'll review with devs about printer being accessible via WiFi after disabling interface. There were a few cases, very rarely, of OOM errors even before WiFi support was released - querying that often might have been a possible cause - anything that "consumes" the RAM and the FW can't "get out of it". Of course let's keep an eye on future errors, even with different set-ups, etc.

Alessandro Pantaleo Prusa Research

[Prusa-Support]

Hello @Pitel, following up on this thread, I checked with devs about printer being still WiFi accessible after switching off on the settings, it is currently expected behaviour, ESP doesn't really turn off. Though no guarantees for now, this might be changed in the future.

Alessandro Pantaleo Prusa Research

[Pitel]

FYI, to disable Wi-Fi, you also need to disable PrusaLink. 👍🏻

[TomaMihai]

Hello all!

Just to add a bit to the discussion; Prusa mini, latest firmware, connection to network via cable, no wi-fi installed or active:

• same problem, OOM error
• causes, either/or, depending on the luck... each of the following increases the chance of a crash; if doing more of them at the same time, again, increased chance for crash: multiple quick refreshes on Prusa Link; two dashboards open on two different computers, clicking the "Storage" tab in the Prusa link, my app; querying the printer once a minute with my DIY printer status notification app
• almost surefire way of making it crash: Dashboard open in my Windows Chrome; Dashboard open in my Mac Chrome browser; clicking Storage on either one of them
• no influence on the OOM error; when the printer was last reset-ed or turned off; Gcode size or complexity
• to the best of my memory, I had no OOM errors when there was definitely a single device that ever connected to the Prusa Link (until 3 weeks ago, there was only one notebook that did this); I remember uploading multiple files with no issue while printing

Thanks all!

Mihai Toma

[DJF3]

Just FYI: I ran into this issue when using Slicer to upload (not print) a file while the printer was printing. Steps:

• In slicer open a 3d model, slice, "upload & print"
• Printer starts printing
• During the print I decided to upload another model without printing it. Slicer: open model, slice, "upload" but not print

RESULT: memory error FW: 4.4 beta2 SLICER: 2.5.0+MacOS-x64-202209060719

[Prusa-Support]

Hello, thank you for the additional reports. All noted for our devs to take a look into it and possibly reproduce. In case of more info from our side on this, I'll update on this thread.

Alessandro Pantaleo Prusa Research

[Pitel]

Happened again with RC1. My setup is still the same (see above comment). This time it happened when I started a new print from printer (not prusalink/slicer). But it seems way more resilient this time, because it happend first time after update almost a week ago, and I'm keeping my printer turned on.

[Prusa-Support]

Hello! Thank you very much for the feedback on this, reported to our devs. We'll update here in case of more info from our side on this. Of course in case of more feedback, feel free to add more comments, anything can be useful!

Alessandro Pantaleo Prusa Research

[mix579]

Got OOM twice today. In one case I was sending a file from Prusaslicer via wifi. The other one, I don't know, it just happened. The printer was just sitting there idling.

[Prusa-Support]

Hello, thank you for the report. How long was the printer switched on, especially during the error while idling? Could it have been switched on for a long time, with a printer reboot resolving it at least for some of time? Was it still with the 4.4.0 RC1 firmware?

Alessandro Pantaleo Prusa Research

[mix579]

Yes, 4.4.0-RC1. This printer has been on for at least two days, printing most of the time. And yes, a reboot resolved it.

[DFEvans]

I've encountered this a couple of times on a Mini. An example this morning occurred after approximately 4 hours - turned on at 0800, OOM by 1210. Two prints had been uploaded via WiFi and printed (PrusaSlicer Upload and Print), OOM occurred during or just after uploading a third print via Wifi.

[Prusa-Support]

As of now unfortunately the cause of the error is not yet totally clear.

As observed in issue https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2612, https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2802, and this one, the cause could vary and not be controllably reproducible.

As per https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2802#issuecomment-1584549108, the main concerns (or apparently recurrent aspects) of the issue so far remain long operating sessions, overlapping inputs, and unstable connections.

Michele Moramarco Prusa Research

[globaltommy]

Just happened to me. OOM error. Half way through the print I woke up my PC that have had the Prusa Link website opened in one of the tabs. The printer started making noise and showing OOM error.

Hope this helps.

[Prusa-Support]

It seems that OOM errors are not frequent but most likely to occur after long or specifically active operating periods, as the temporary data probably fills up the printer's memory - whereas, a simple reboot will theoretically solve the problem.

However, this and the other linked/duplicate issues above remained mostly silent since last Summer, and the firmware is significantly different now that it is consistent among all "Buddy firmware" printers (MK4, XL, MINI).

The issue may be obsolete by now so I wonder if the problem occurred to any of the participants of this thread, also in recent times with FW 5.1.0 or newer.

Michele Moramarco Prusa Research

[Pitel]

@Prusa-Support Yes, happened to me just yesterday (original MINI, FW 5.1.2). Crash in some media_prefetch (or some similar named) function. But, I'm now using PrusaConnect.

[DFEvans]

However, this and the other linked/duplicate issues above remained mostly silent since last Summer

Prusa support has previously indicated annoyance when users keep reporting that issues are still present, or adding "me too"s to issues, so I have held back from doing so lately.

I had an OOM this morning, blue screen and crash dump attached. It's rarer than it was on previous firmware versions, but still occurs perhaps every week or two. dump_buddy.zip

[Prusa-Support]

Our developers keep up the work to make the memory as static as possible, release after release, reducing chances of heap memory fragmentation which may occasionally be a cause of OOM errors. However, in a few cases with Prusa MINI and the most recent firmware, new OOM occurrences were observed in relation to the binary G-code decompression. Our developers are already working on it but we would appreciate knowing if OOM errors could drastically drop on the most recent firmware if the binary G-code export is temporarily disabled in Prusa Slicer.

.

Prusa support has previously indicated annoyance when users keep reporting that issues are still present, or adding "me too"s to issues, so I have held back from doing so lately.

Thanks for the concern and I must recognize that multiple me-toos in a row are hardly helpful but there must be a terrible misunderstanding! Comments are welcome and we keep collecting any bit of useful feedback from them. Comments - and most importantly participation - can also give us a rough overview of how widespread is an issue. Please don't hold yourself back if you feel like sharing more! 🙂 Simple common sense will be enough for a sustainable and fruitful conversation. ✌️

Michele Moramarco Prusa Research

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[danopernis]

Just to let you know, we are still working on the issue. Unfortunately it involves rewriting a lot of the "media prefetch task" to free enough RAM to then set it aside statically for the heatshrink library to prevent memory fragmentation.