Hello,
I've been dealing with an issue lately where my printer will randomly cancel the ongoing printjob and I get a message telling me that my printer was reset in octoprint.
This issue seems to occur only when both raspberry pi and my display (reprap full graphic controller) are connected. I've tried printing the exact same gcode with the display disconnected and with the USB disconnected from the RPi.
The other symptomps that may or may not be related are: my SD card not being initialized and I'm unable to shutdown octoprint, as it always restarts by itself.
I've not yet tried running in safe mode, but I've tried reinstalling both octoprint and my printer firmware(a custom version of marlin 2.1.1)
I'm running octopi 1.8.7 and marlin 2.1.1. Additionally, I'm also using arcwelder plugin in prusaslicer.
My hardware is: Reprap discount full graphic smart controller, 50cm display cables, MKS Gen L, TMC2208s in standalone mode, Rpi3B and a relay board for the lighting. I'm using a 30cm usb cable between Rpi and mainboard, and a 300W buck converter with 20AWG wires for the 5v power.
My only theory now is that my display cables are somehow faulty, either interfering with the USB serial communication or shorting the reset pin to ground, which would reset the mainboard. But I'm at my wit's end.
2023-03-04 21:16:33,464 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: !! KILL caused by KILL button/pin - start
| Last lines in terminal:
| Changing monitoring state from "Offline" to "Opening serial connection"
| Connecting to port /dev/ttyUSB0, baudrate 115200
| Changing monitoring state from "Opening serial connection" to "Connecting"
| Connected to: Serial<id=0x633dccd0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=100.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
| Send: N0 M110 N0*125
| Recv: start
| Send: N0 M110 N0*125
| Recv: PowerUp
| Recv: Brown out Reset
| Recv: Marlin 2.0.9.5
| Recv: echo: Last Updated: 2022-07-29 | Author: (none, default config)
| Recv: echo: Compiled: Mar 4 2023
| Recv: echo: Free Memory: 16663 PlannerBufferBytes: 744
| Recv: echo:EEPROM version mismatch (EEPROM=V87 Marlin=V86)
| Recv: echo:Hardcoded Default Settings Loaded
| Recv: pages_ready
| Recv: Error:!! KILL caused by KILL button/pin
| Recv: start
These appear multiple times. If you did not press the reset button, you may check the hardware.
You may have a close look on this:
2023-03-04 21:24:13,657 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: !! KILL caused by KILL button/pin - Printer halted. kill() called!
| Last lines in terminal:
| Recv: echo:Hardcoded Default Settings Loaded
| Recv: pages_ready
| Recv: Error:!! KILL caused by KILL button/pin
| Recv: Error:Printer halted. kill() called!
| WARNING! Received an error from the printer's firmware, ignoring that as configured but you might want to investigate what happened here! Error: !! KILL caused by KILL button/pin - Printer halted. kill() called!
| Recv: //action:poweroff
| Send: N0 M110 N0*125
| Recv: P start
| WARNThe received line contains at least one null byte character at position 1, this hints at some data corruption going on
| Recv: PowerUp
| Recv: Brown out Reset
| Recv: Marlin 2.0.9.5
| Recv: echo: Last Updated: 2022-07-29 | Author: (none, default config)
| Recv: echo: Compiled: Mar 4 2023
| Recv: echo: Free Memory: 16663 PlannerBufferBytes: 744
| Recv: echo:EEPROM version mismatch (EEPROM=V87 Marlin=V86)
| Recv: echo:Hardcoded Default Settings Loaded
| Recv: pages_ready
| Recv: Error:!! KILL caused by KILL button/pin
| Recv: Error:Printer halted. kill() called!
In addition, bad USB communication appear to be happen.
2023-03-04 22:29:03,355 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2023-03-04 22:29:15,021 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 3613, 'printer_state': 'OPERATIONAL'}
2023-03-04 22:27:17,553 - octoprint.startup - INFO - ******************************************************************************
2023-03-04 22:27:17,558 - octoprint.startup - INFO - Starting OctoPrint 1.8.7
2023-03-04 22:27:17,563 - octoprint.startup - INFO - ******************************************************************************
This is a clue for power cycling the Pi.
This can lead to the following error due to a corrupted file system on the Pi's SD card.
2023-03-04 23:14:59,905 - octoprint.plugin.core - ERROR - Exception while initializing plugin softwareupdate, disabling it
Traceback (most recent call last):
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/plugin/core.py", line 1961, in initialize_implementation
implementation.initialize()
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1688, in wrapper
return f(*args, **kwargs)
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1688, in wrapper
return f(*args, **kwargs)
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1688, in wrapper
return f(*args, **kwargs)
[Previous line repeated 4 more times]
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/plugins/softwareupdate/__init__.py", line 129, in initialize
self._load_update_log()
File "/home/MatS/oprint/lib/python3.9/site-packages/octoprint/plugins/softwareupdate/__init__.py", line 545, in _load_update_log
before_cleanup = len(data)
TypeError: object of type 'NoneType' has no len()
Please don't mix up OctoPi and OctoPrint. The version number you give is OctoPrint.
OctoPi is version 1.0.0
I know about the overheating error, that pops up sometimes on boot, but never caused a problem. The Rpi is running at 40-60°C according to ResourceMonitor plugin.
That might be because the SD card is not initiating correctly, because once I send M21 it works without a problem.
The brown out reset is from me updating the firmware, and getting a bootloop for some reason(fixed now).
I will have a look at the board to see if maybe some loose bit of wire is shorting the reset pin/button. It's intermittent enough that it might be that. The weird thing is that this only happens when I have both RPi AND display connected.
I tried both disconnecting the display (printing from octoprint) and disconnecting the USB cable from the RPi (printing from SD card with display connected.)
Both of these cases were a success, but once I connect them both at the same time, I get this error randomly during a print. The only thing I can think of is that somehow the display and USB are interfering. Maybe the mainboard tries to send data to the display while receiving data over USB and that makes marlin crash? I don't know.
Thanks for clarifying that. I should have read the instructions better.
In this case, the problem looks pretty easy from this C.E.T.'s p.o.v.
The 5volt supplies that come with the pi,, the usual wall wart, are well known to be a bit puny.
A 5 volt, 5 amp psu for the pi, and a case with heat sinks and for the pi. I have several banana pi m5's here, all running klipper and octoprint 1.8.6. With a UPS on the whole thing, a print that takes 2 weeks to complete is not a problem as long as I'm present to feed it a new roll of filament when it runs out. The banana pi is running a currently updated armbian bullseye. Uptimes are in months. Usually from an update that needs a reboot to update that needs a reboot. I have 1 now elderly pi4b that is happily running a 1500 lb Sheldon lathe, bought it way back when they were affordable. Unlike wintel stuff, arm stuff doesn't crash.
In either case, it still sounds like a puny power supply. I have observed two of my printers whose 24 volt supplies folded back to around 15 volts if the start up code, didn't sequence the printer warmups properly, predictably, they crashed but usually during the warmup phase.
And one case where I just plain used up the 40 watt OEM hot end heater, it could make the PETG temp, until the ejector came on, then it didn't have enough heat to melt the filament, klipper detects the low temp and shuts it down. Measuring the resistance of the heater, it was down to about 27 watts. A replacement 70 watt heater and pid recalibration fixed it right up.
I thought so too, but the stock power supply is rated at 360W according to the BOM and I've measured the consumption to be around 250W peak. Although it would make sense why it only happened so far while printing at 250°C on the hotend with 105°C bed. The power consumption does go up with higher temperatures, correct?
So if I'm right, it might be just a case of replacing the stock PSU with a 500W or something similar.
How old is that PSU. And yes, the average power goes up with the temps.
What are you printing that needs 250C nozzle temps?
And is the heater in the hot end strong enough its temp doesn't sag when filament is flowing? I just replaced an older 40 watt heater that had faded to about 27 watts, when the flow started, it didn't hold up the temp and klipper shuts a print down if the hotend gets 4C under the set temp. Marlin likely does something similar...
Whatever, its sure a nuisance, particularly if there's no log to explain why that the user can see.
The PSU is as old as the printer itself (around 5 years give or take)
I'm printing PMMA and PP although I've not dialed it in yet, so these temps are more like a starting point.
The heater is 70W (overkill, I know) the hotend itself is E3D cyclops v1.
I also know that bad power connections to the motherboard could be the issue, causing higher voltage drop if they're loose, but chances are that's not the case, since the printer likely would've burned down before any of these issues. I've also rewired the whole thing with 14awg wire and ferrules about a year ago.