Printer occasionally pauses without moving nozzle away from part and OctoPrint becomes unresponsive

Get Help
1

What is the problem?

This is frustratingly temperamental issue. Seemingly completely at random, and not that often, my print head just stops moving. Temps remain set. No retraction, no movement away from the print. When I open OctoPrint it seems to be stuck in a rapid cycle of "paused" "resuming" "printing" "paused" "resuming"...etc and is unresponsive. I have to restart to get it to work again. The printer is seemingly ready to go still awaiting a command i.e it holds all the temperatures and just sits there oozing and melting the part!

What did you already try to solve it?

This has been happening for 6 months at least. It doesn't happen that often but it can be on prints of any size at any stage of the print. If it fails and then I run exactly the same print again it will more than likely not fail a second time. I have tried a fresh install of Octoprint from a new image on a new SD card (and therefore upgraded Python). The problem has not got any better or worse from the addition or removal of add-ons although I have never run octorint with no addons at all.
I have not yet had the same problem when running the printer directly from the SD card - only ever via OctoPrint.

Have you tried running in safe mode?

no. as the problem is so sporadic

Complete Logs

I'm hoping someone can direct me to the most appropriate log. I have looked in the "logging" section of OctoPrint and there is nothing stored from around about the time of the last time the fault occurred. My serial.log does not have anything in it and my octoprint.log only includes details from today. Is there something else? I have a timelapse video showing it but that's all I can see. Sorry. I must be missing something.

Additional information about your setup

browser.user_agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
connectivity.connection_check: 8.8.8.8:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 1400
env.hardware.ram: 915718144
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 3 Model B Plus Rev 1.3
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.5.3
printer.firmware: Marlin Ultimaker2; Sprinter/grbl mashup for gen6

2

To get a serial.log, you have to enable it first (click the blue link for instructions). For us to help I think we are going to need both the octoprint.log and the serial.log captured when it fails. From the OctoPrint Settings page, you can open Logging and delete the logs before you start a print. Then if the print fails, you'll have captured just the failure. If you are doing multiple prints in a row, starting new logs once a day would probably be enough.

1 Like
3

That's great thanks. I can imagine it being a while before I can reply to this thread now that I kinda want my print to fail!

4

I have had quite a few successful prints with no problems since posting the above and then activating the serial log. Typical!
Each day, I have been deleting all the logs and then restarting the server. The only strange issue that I have observed it that on one occasion the server seemed to be unresponsive - it did not load the UI nor the webcam and even the physical reset button on the Pi did not work. Despite this, the print did not fail.
I have attached the logs associated with this particular event in the hope that something stands out as the problem?
I do not know why but I seem to have 2 x serial.log files. The one with the date attached to the end it apparently too large to upload but I suspect that this is the one that you need? What do I do about this?

octoprint.log (98.9 KB) serial.log (6.1 KB)

5

zip it :slight_smile:

6

:+1:
serial 2021-04-04_19-20-00.zip (1.4 MB)