Quick update. In looking at past log files on my Ender 3, The update to 1.5.0 worked ok, is it only the 1.5.1 and 1.5.2 that is causing the issue.
Jeff
This is even more confusing, and makes it look more and more like this problem is coincidence to me. Since there were no changes anywhere near printer communication, I can only assume it was either the update process, or coincidence, or some mysterious ghosts that we have no idea about. The number of people reporting this seems too high to be complete coincidence, but then I am yet to see a pattern, evidence or other significant indicator of what this might be.
I wonder if it would be worth trying to roll the update back to 1.5.0/1.4.2, to try and rule out any code changes made (if any?) that would impact this. Shot in the dark, but if it starts to work again then that would be a massive step in the right direction
How do you roll back to 1.4.2 or even just 1.5.0 via Putty?
Assuming OctoPi (if not, the path to your venv)
~/oprint/bin/pip install OctoPrint==1.5.0
Give it a go, however if this solves it please be prepared (as you seem to be) to try out any fixes, rather than sticking with 1.5.0, we tend not to like recommending a downgrade.
While pip is in the bin directory when I try to run this command I get "command not found".
Jeff
To downgrade to a version (1.4.2 is the example):
~/oprint/bin/pip install https://github.com/OctoPrint/OctoPrint/archive/1.4.2.zip
sudo service octoprint restart
It doesn't recognize the pip command. Looking at pip it seems to be a python script. How do I run it?
It's that pip problem showing on OctoPi or your nuc? Because that command line is for OctoPi only.
It is on my RPi3b+ running Octopi. I did install it using apt install python-pip but it must put it somewhere other then ~/oprint/bin
Still didn't work. I can just wipe the card and reload the Octopi image 0.17 ... trying not to do that/
Jeff
I used:
~/oprint/bin/pip install --force-reinstall OctoPrint==1.4.2
sudo service octoprint restart
@AevnsGrandpa and it works for me. I still need to do more testing to make sure it works 100%.
Update from my end: OctoPrint 1.4.2 printing in safe mode worked without any failures or errors on the serial interface.
I have reflashed the SD card with the latest version of OctoPi and upgraded both the Python AND OctoPrint back to the latest version and will try again, firstly with the default out the box plugins, and if that works/fails safe mode to confirm.
If anything fails, I shall upload the logs.
My failed after 5hrs with 1.4.2. too. My next step is to run it in safe and see if that works.
Communication error
There was a communication error while talking to your printer. Please consult the terminal output and octoprint.log for details. Error: Too many consecutive timeouts, printer still connected and alive?
Printer: Monoprice Maker Select Plus
Raspberry pi 4
octoprint.log (1.0 MB)
That's a different kind of error from a "SerialException" though - this one is you printer stopping responding to OctoPrint's attempts to keep a communication going, a SerialException is the whole connection breaking down on a level closer to the bare metal.
1 Like
Update 3: I have rebuilt the OctoPi instance using the latest OctoPi 0.17.0 image, upgraded the OctoPrint instance to 1.5.2, and upgraded Python to 3.7.3.
Third Party Addons installed and running:
Creality Temperature (1.2.4)
Creality-2x-temperature-reporting-fix (0.0.4)
PrintTimeGenious Plugin (2.2.7)
UI Customizer (0.1.1.1)
Happy to say after a five hour print, no serial issues. I shall continue to add plugins one by one and conduct a >3 hour print each time to ensure no issues.
Addons I plan to reinstall:
Bed Visualizer
Navbar Temperature Plugin
Octolapse
If all the above work as planned and generate no serial issues, I shall install the 'Tuya Smartplug' app.
I'll provide updates as I go.
@foosel, would you like me to try something specific or continue to provide updates?
I reloaded the micro-SD from scratch using the 0.18 Octopi and 1.4.2 of OctoPrint. Am going to hold off updating to any of the 1.5.x version for know till I see a fix or solution. Thanks for the help on the roll back, never could get it to work.
Let us know if you either continue to have issues, or if it is issue free. From our perspective, it would be nice if you could keep a backup of the current SD card (using an imaging tool) & try and update again to see if it causes the same problems... but I appreciate you may not want to. Depends, we still can't find a pattern to these problems.
1 Like
For now I still lack any kind of clue, so just keep the updates coming I guess. Needless to say I cannot reproduce this at all here.
1 Like
I don't see a serial exception there, that's a timeout. This topic was about SerialException only, to try and work out a pattern.
I'm gonna jump in here, even though I am not experiencing the problem right now. I try to run with the minimal amount of plug-ins anyway.
I think foosel is both correct (that she didn't change any code to the serial port handler), and incorrect that problem occurred when the upgraded code was added.
Here's my take, after years of writing embedded code (which is basically what Octoprint is) and dealing with multiple languages: I think we are seeing the real-time limitations of Python.
Python is a dynamic language running with two parts: A language interpreter, and a garbage collector. The garbage collector runs in the background cleaning and scavenging memory of the dynamic parts of the language, both of which are memory and CPU hogs. The language interpreter is also a hog, and that is interesting to note that even Java has a pre-compiler for performance reasons.
Serial port timeouts and serial exceptions is a sure indication that the software can't get back to the USART (the hardware that controls the USB) hardware quick enough to extract a byte out of the USART before the next one comes in. In this case, it is the Python library(or Raspbian) that is doing this based on a hardware interrupt by the USART. I don't know how the Python library is written, nor how preemptive scheduling works on Raspbian, but I suspect that the load of Python stuff is preventing the interrupt of the USART from extracting the data properly from the USART, thus giving the errors. That's probably why 1.4 works fine, but 1.5 doesn't, simply because of the added stuff in 1.5.
What can be done? Dunno. It's no surprise that Marlin (which is written in C) performs so well even on 8 bit processors). C is a static compiled language that needs no background processes running, With a real-time OS (or no OS), timing is generally not an issue unless the software is designed poorly. Software design and software architecture is a major problem when building complex systems, and I have personally "fixed" many complex systems by having the developer document their architecture and when that is done, the problems are immediately obvious. My last position (before I retired) was Head of IT Architecture in a major airlines, so I have some experience in these matters.
The higher up the abstraction you get in computer languages, the worse your performance will be.
Perhaps running faster processors will solve the problem. I.e.: Kill it with hardware.
I notice on my Octoprint 1.5 on a Pi 2B+ (with only a couple of plug-ins running, my CPU load is approaching 70%, and the processor is throttling back based on heat). 1.4 never got that type of load. I probably won't upgrade Octoprint without getting a Pi 4B+.
If I where re-writing Octoprint (which I won't be), I probably would write it in C or C++ (C++ can be made static) for performance reasons.
Just my $.02. Better put on my asbestos suit.
I'm using Octoprint 1.5.2 on a Pi3 and even with the webcam stream open in my browser, I barely see system load higher than 0.2, CPU cores stays under 12% most of time and three quarters of RAM are free, still I experienced some kind of port timeout (even if not the same as most of users here).
I'm afraid you can't kill this with hardware.
On the other hand, I installed the "Dry Run" plugin and tried to simulate some Benchy prints after taping the + pin on my USB cable, and it seems that the timeouts are not occurring anymore... I'll try some real print in the next days and see.