Hello, I have noticed, in the past 3 months, that as I print using Octoprint, when I check the print status away from the printer, through Wifi, a delay of access of the info is created due to a bottleneck of processor resource availability and what happens is, trying to satisfy both my request and the actual work of printing being done, octoprint decides to skip a few printing steps to respond to the status request and then goes back to it's tasks. The result is a noticeable shift in the position of the print and thus, a ruined print after a few days of printing.
To resolve this issue, I have gone along with printing without my checking of the status and everything goes well. But impatient as I may be at times, the point of Octoprint is to be able to check of progress and, well, the problem!
Since you didn't ask a question and you didn't provide any (useful) details, I guess you just needed to vent.
If you do want our help, please start with (the blue text are links):
Need help? Read this first! Remember to provide version numbers, relevant log files and general information about your setup. Problem solved? Mark the solution! WE NEED LOGS TO HELP YOU!
3 Likes
Thank you for your prompt "response". As it might have been taken for a rant of some sort, I don't really have time and certainly not the money after so many fails by Octoprint. My question was, has anyone ever encountered this problem?
I have Octoprint 1.4. 0, dashboard plugin 1.13, display layer progress plugin 1.22. 1, filemanager plugin o. 1.4 and fullscreen plugin 0.0.5.
Are you seeing cpu or memory being maxed out? Displayer layer progress plugin has been know to cause issues with print quality, you could try disabling that and retest.
I have a raspberry pi 3b+ with 50 plugins installed and a web cam and have not had issues with the connection via web interface affecting the print. I do have the CPU throttling turned off though so it always runs at 1200MHz.
You might repeat this experiment in Safe Mode to make sure that one of the third-party plugins isn't causing this.
And yet, it's good to keep your browser session running if you're curious about the progress. Opening additional browsers (or a new browser having closed it earlier) will indeed have a moment of single-core activity which is pegged out. And yet, the 3B+ has four cores and shouldn't be taken to its knees as a result.
If it were me, I might run a remote ssh session and run htop to look at how busy the four processors are. Then open up another browser and watch how one core will peg out but that this doesn't affect the main Python thread (core) which is running OctoPrint to stream your print job.
The 3B+ has 1GB of RAM which should be sufficient. If you've installed something in which a TFT screen or similar is running from the Pi itself then part of that installation may have installed "the Desktop" (the x11 windowing system). This uses more memory and resources. If on top of this you're also loading a local browser within the Desktop of Raspian on the Pi then this uses more RAM/processing as well.
I unloafed the display layer and I must admit that remote access to the pi is much faster and smoother. Thank you for this suggestion.
I really enjoyed this approach to find the issue. In my case, I don't use any tft screens, nore do I have really anything else on the pi that would require resources other than that of octoprint. Thank you for your suggestions.
So, what Type of Raspberry Pi are you actually using?
@Ewald_Ikemann, I think it is a RPi 3B+ from the title of the thread.
1 Like
Alright then, it would be good to see if Safe Mode behaves as expected.
