Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
RPi has heatsinks and a fan. I even changed the printer cable with a way better one. I made sonar more “sensitive” but i have an ethernet cable connected too just to be sure. And i’m still loosing connection with the MCU 80% through the print…
MCU file Errors:
logging.info(“Sending MCU ‘%s’ printer configuration…”,
self._name)
for c in self._config_cmds:
self._serial.send(c)
else:
for c in self._restart_cmds:
self._serial.send(c)
# Transmit init messages
for c in self._init_cmds:
self._serial.send(c)
except msgproto.enumeration_error as e:
enum_name, enum_value = e.get_enum_params()
if enum_name == ‘pin’:
# Raise pin name errors as a config error (not a protocol error)
raise self._printer.config_error(
“Pin ‘%s’ is not a valid pin name on mcu ‘%s’”
% (enum_value, self._name))
raise
def _send_get_config(self):
get_config_cmd = self.lookup_query_command(
“get_config”,
“config is_config=%c crc=%u is_shutdown=%c move_count=%hu”)
if self.is_fileoutput():
return { ‘is_config’: 0, ‘move_count’: 500, ‘crc’: 0 }
config_params = get_config_cmd.send()
if self._is_shutdown:
raise error(“MCU ‘%s’ error during config: %s” % (
self._name, self._shutdown_msg))
if config_params[‘is_shutdown’]:
raise error(“Can not update MCU ‘%s’ config as it is shutdown” % (
self._name,))
return config_params
def _log_info(self):
msgparser = self._serial.get_msgparser()
message_count = len(msgparser.get_messages())
version, build_versions = msgparser.get_version_info()
log_info = [
“Loaded MCU ‘%s’ %d commands (%s / %s)”
% (self._name, message_count, version, build_versions),
“MCU ‘%s’ config: %s” % (self._name, " “.join(
[”%s=%s" % (k, v) for k, v in self.get_constants().items()]))]
return “\n”.join(log_info)
def _connect(self):
config_params = self._send_get_config()
if not config_params[‘is_config’]:
if self._restart_method == ‘rpi_usb’:
# Only configure mcu after usb power reset
self._check_restart(“full reset before config”)
# Not configured - send config and issue get_config again
self._send_config(None)
config_params = self._send_get_config()
if not config_params[‘is_config’] and not self.is_fileoutput():
raise error(“Unable to configure MCU ‘%s’” % (self._name,))
else:
start_reason = self._printer.get_start_args().get(“start_reason”)
if start_reason == ‘firmware_restart’:
raise error(“Failed automated reset of MCU ‘%s’”
It’s recorded in the logs when the MCU shuts down during a print. I also noticed it in the temperature graph today after switching to Fluidd. Also can i use the statement u sent me on my printer.cfg and add a max_temp line so i can increase it?
Nope, that wasn’t the issue after all… Could it be the Micro USB cable? I swapped it for a better one, but maybe it’s too long? I’ve reflashed Klipper twice, switched from Mainsail to Fluidd, and still no luck. Could the problem be the stock breakout board that came with the Ender 6? Or maybe the wiring to my CR Touch?
I’ve finally dialed in my settings for near-perfect prints, but I just can’t get one to finish. klippy new.zip (1.6 MB)
The known reasons for this error are in the link I provided above. I have not seen an MCU overheat, nor have any of the quoted attempts been a solution.
Okay, you’re right. I’ll take a closer look and report back with my findings. It might take some time, though. It’s best to leave the thread open so others with the same or similar issue can follow along
I removed the camera, and now I’m no longer getting mid-print errors. The problem is, I need the camera for remote access.
Sometimes, the printer and RPi shut down at the start of a print when the toolhead homes. Could this be a faulty wire touching something it shouldn’t? is there a simpler fix I should try first? Or should I start checking for a damaged wire or bad crimp right away?
I forgot to download the Klippy log when it happened, but it wasn’t just a lost connection—the whole printer powered off, fans and everything. As for the RPi 3B+, it shut down too. The fan was running, but only the red light was on, and I couldn’t even reboot it from the web interface.
I should probably upgrade to a Raspberry Pi 4 in the future. I already have a clear acrylic case for it, and it even has a fan slot. I found it on sale and couldn’t resist!
I can’t comment because you haven’t listed all the apps or OS that are running on your rPi 3B+.
My first recommendation would be to restart with only Klipper/Moonraker/Mainsail-Fluidd on your rPi and see how things work.
If things are working fine, then add the apps and peripherals one by one to see what, if anything, overloads the system and causes you to have your disconnection errors.
That will help you decide whether or not you need to upgrade your rPi.
It is not fully clear where the issues with the webcams are coming from. It could be (but is not limited to):
On many SBCs, including the RPi 3, the USB ports are a bottleneck as there is effectively only one controller, and USB is shared with other devices on the board.
High bandwidth requirements of the webcams.
Poor firmware implementations in the cameras.
You could try:
Different combinations of USB ports for connecting the printer board and webcam.
A different webcam.
Using a good quality USB hub in between.
It should likely be a MTT-capable hub. Unfortunately, it is often unclear if a hub has this ability.
I’ve already tried every possible USB combination. My current camera is a Creative model with a weird built-in video call auto-mute feature. I was planning to replace it anyway since the feed is grainy, even in bright daylight.
The thing is, I want to get a Logitech 4K camera for high-quality time-lapses, but there’s no way my current Pi can handle it. With that in mind, my next goal is to upgrade to a better Raspberry Pi and get a high-speed Anker USB hub so i can have a multi-cam setup in the future.
Alright! After a ton of printing and testing, I can now say with 100% certainty that the problem was… (drum roll, please…) THE POWER SUPPLY!
Turns out, the start print sequence was pulling too much power since both the extruder and bed were heating up at the same time. The fix? I simply added a G4 (dwell) command between them to stagger the power draw, and ever since,no more issues!
