MCU disconnect sadness

General Discussion
1

This is the second night in a row that this printer (Prusa MK3S) has disconnected after printing for a good amount of time. Lets go through the proposals on the docs:

Last night, I tried using a cable that I know is good, I’ve been using it for the past week with another printer (Lulzbot Taz6) with not a single mcu disconnect.

I’m not using a raspberry pi, I’m using a full server that should have plenty of 5v power inside it for the usb buss and definitely isn’t throttling internally due to lack of power supply voltage.

I’m not entirely sure how to check if the printer’s power supply is overloaded. Maybe someone could explain here.

To my knowledge there are no broken wires on the printer, I did a fairly substantial check earlier this month.

The 5v power supplies are not mixed.

2 nights ago I came in to both of the Prusas in MCU disconnect. Last night one of them made it through the night and the other (the one being talked about above which was on a different cable) disconnected. TBH I was hoping for this to just be a bad cable since that’s a much simpler fix. Now I fear that there is something wrong with Prusas running Klipper.

2

klippy-1.log.zip (777.8 KB)
Almost forgot to upload this guy

3

I’m not the expert here but looking at your log:

bytes_retransmit=604612 
bytes_invalid=1051164 
stalled_bytes=301

All the way through until it craps out. This looks like a very unstable connection between RPi and MCU

4

I noticed that in the log but I’m not an expert at reading the klippy log file. Does that mean that the connection is always unstable? Or is it getting unstable toward a certain point or around a certain time or something and that causes it to shut down fairly quickly

Do you think it’s a USB cable issue still or a problem with the printer itself. As I think I mentioned last night I used a cable that I thought was good because it has been working on another printer for about a week now. Is there anyway I can use the clippy log file to “test“ the USB cable?

5

I cannot give you a profound answer. Your log starts with very high counts of bytes_retransmit and
bytes_invalid.
Comparing it to my printer, I have some bytes_retransmit (lower 10) and 0 bytes_invalid.

In my interpretation these two values are a direct reflection of the serial connection quality. For the reasons I’m just spitballing:

  • Cable quality / length
  • Crappy USB port
  • Obscure driver issues, i.e. FTDI etc.
  • EMI
  • 3rd party software trying to access the port
  • RPi undervoltage problem
  • Faulty MCU board
  • …

Does dmesg show any errors?

6

Apparently earlier prusas had faulty usb2uart chip firmware as someone told me on Reddit this morning. Flashing the firmware on there seems to have fixed the issue. At least bytes retransmit is gone

7

This one?

Edit:
For future reference, this is also mentioned in the Klipper default cfg for this printers.

1 Like
8

In case you are getting “lost communication with MCU”, check also this page Frequently Asked Questions - Klipper documentation and search for “modem manager” which is Linux service that keeps randomly causing these.