What is the problem?
I've had my Ender 3 Pro for a few months and have been printing from OctoPi from day one. I recently printed my longest print which two 24 hours. I rested the printer for about a half a day and then started printing another item estimated to take 14 hours. about 4 hours in, it just stopped. I send it to print again and again at the same point in the print process (the two items look to be around the same height) it stops printing again.
At this point I think its the GCODE so instead of printing the same piece, I print another item estimated to take 5 hours. about 2 hours in, it stops too. This time I was by the printer and saw that the Ender 3 Pro screen flashed, showed the logo, then the regular screen. It looked like it rebooted.
What did you already try to solve it?
I searched for possible issues and saw that it could be the power supply unit (PSU) to the Raspberry Pi. I changed it and saw that i no longer had that power issue warning in OctoPi. Thinking I solved the issue, I went back to print the first one that failed. Right around the same point it fails once again.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, what kind of hardware precisely, ...)
OctoPrint 1.3.12
Ender 3 Pro
Not sure about firmware - i haven't touched it.
Here's my Log FIle: octoprint-2020-01-19.log (74.3 KB)
2020-01-19 17:58:57,471 - octoprint.util.comm - ERROR - Something crashed inside the serial connection loop, please report this in OctoPrint's bug tracker:
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 1762, in _monitor
self._handle_ok()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2232, in _handle_ok
self._continue_sending()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2354, in _continue_sending
elif job_active and self._send_from_job():
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2873, in _send_from_job
result = self._sendCommand(line, tags={"source:file", "filepos:{}".format(pos), "fileline:{}".format(lineno)})
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 3099, in _sendCommand
enqueued_something = process(cmd, cmd_type, gcode, subcode, on_sent=on_sent, tags=tags) or enqueued_something
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 3071, in process
self._process_atcommand_phase("queuing", cmd, tags=tags)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 3392, in _process_atcommand_phase
handler = getattr(self, "_atcommand_{}_{}".format(atcommand, phase), None)
UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 0: ordinal not in range(128)
Looks like there's an @ command in your gcode file that's causing issues. Please share the file as well so we can investigate.
If it doesn't I'm a bit at a loss tbh. Files look fine on first look, stack trace indicates an encoding issues while trying to parse an @ command however.
I looked in both files but there aren't any @ symbols in the files. I didn't do anything fancy when slicing. I use Cura and the only changes I usually make are setting the temperature of the extruder and bed, % fill, supports, and a skirt. Very basic, nothing crazy. I never edit the raw GCODE either.
Just thought of something. Every print up until these, I've always used the timed timelapse. For these prints I switched to Z-Axis time lapse technique. Would that cause the issues?
I looked at the lines of code where the files failed and they don't have Z axis changes:
Printed the smaller of the two files and it failed again at the same spot while is Safe Mode.
I isolated that layer, edited the GCODE file to only have that one layer, and hit print. It printed successfully.
I think I will try to re-encode the file and generate a new GCODE file and kill the timelapse to see if that works.
This looks like the replacement character. The thought would be that the firmware has some weird spot in it which tries to send an unknown encoding under some circumstance.
I believe I've narrowed the root cause... Time-lapse.
I reprinted the small file on the OctoPrint without safe mode, but stopped the time-lapse entirely. The file I used was the same file that failed twice before. This time it printed successfully!
To confirm, I'm printing the larger file right now without time-lapse. I should be about another hour away from knowing if it will succeed or fail.
For trouble shooting purposes, all I did originally was switch from a timed time-lapse (every 10 seconds) to Z-Axis time lapse (all settings I left as default)
The larger file that failed was able to print successfully once i disabled time-lapse.
My hardware is Raspberry Pi 3 Model B V1.2
32 Gb generic SD card
Camera is an old Logitech "eyeball" style web cam.
Thanks for your patience and guidance when trying to get my prints back working!!
Now the interesting question is - does this stuff only fail on z-triggered timelapses for you, to which you switched when the trouble started, or do timed timelapses also not work now with the files in question?
Maybe the comm.py's complaints weren't the reason for getting caught up, I'm guessing. Clearly, those errors should still be in the log if you printed the exact same gcode.
I'm starting to think the same actually, but then again they indicated a full blown crash in the serial loop which would cause a mid print stop. I just can't see the relation to the timelapse mode here.
Then again I just spotted this:
2020-01-19 06:36:18,174 - octoprint.plugins.pi_support - WARNING - This Raspberry Pi is reporting problems that might lead to bad performance or errors caused by overheating or insufficient power.
!!! UNDERVOLTAGE REPORTED !!! Make sure that the power supply and power cable are capable of supplying enough voltage and current to your Pi.
And I strongly suggest to fix this issue first before anything else because undervoltage can cause ALL kind of weird and might very well be the core reason here.
Yeah, seriously. This last "success" could have simply been that the air conditioner, refrigerator or microwave oven wasn't robbing power from the wall circuit.
I also saw the Undervoltage error. I switched out to another power source for and the power warning went away. I printed again with the new power source and the print failed. It was only when I stopped the timelapse on z-axis that the print was able to successfully print. Before that my settings were on Timed timelapse and I never had it stop mid-print.
Did you test it with both z-based and time-based timelapses?
Almost all my prints up until these two i've used time-based timelapse. I did not use timed-based with these two ever. I just tried reprinting one of the failed prints with time-based and it completed successfully.
Is your part sliced using the "vase mode"?
No. I didn't know what this was until you just mentioned it. I looked at my Cura settings and this is not sliced in Vase Mode.
Do you have a purge stack (typical of multiple extruders or multiple colors, for example)?
This is an Ender 3 Pro, so only one extruder
Does your printer include some sort of nozzle cleaning cycle?
The only nozzle cleaning is the initial wipe before the printer begins printing the item
and might very well be the core reason here.