MCU lost communication: I'm stumped

General Discussion
1

Basic Information:

Printer Model: Anycubic Kobra Neo
MCU / Printerboard: [stock] HC32F460 / TriGorilla Gen V3.0.6
Host / SBC: Pi 5 2 GB
klippy.log
klippy.log (1.8 MB)

Describe your issue:

Thanks in advance for your help!

My printer consistently throws an MCU lost communication during long prints. This usually happens between 2 and 4 hours into a print.

Steps taken so far:

  • try different USB cables, routed away from motors
  • try without WebCam
  • reload laptop from Ubuntu Server to Debian
  • replace laptop host with a Pi 5 2GB
  • re-flash for a lower baud rate (115200)
  • check PSU voltage, it’s stable 24 V with very low ripple
  • check controller 5V, very stable
  • ensure all wiring is secure and terminals tight
  • check that control board cooling fan is functional. MCU is cool to the touch, even after running for some time.
  • try several prints with the bed and extruder temperature set to 15 degress C (no filament loaded) to ensure PSU load was not a factor.
  • leave printer on for long periods of time, but not printing. No loss of communication in that case.

After each step, I run a long print and get MCU lost communication after 2+ hours.

Any ideas on further troubleshooting steps? I’m out of ideas, short of replacing the control board.

Thanks!

IMG_2657
IMG_26571920Ă—2560 570 KB

2

You have already done a good job in trying to pin down your issue.
Unfortunately, there is not much more we can contribute: Timeout with MCU / Lost communication with MCU

3

I appreciate the quick reply @Sineos!

I’d be really interested to learn if there is anyone with a Kobra Neo having good success with Klipper on the stock TriGorilla control board.

4

Your log indicate error “Got EOF when reading from device” line in the log 2915 after that you are getting MCU Timeout error.
Your error is falling in category of this error Got EOF when reading from device

Also found some resources here and they indicate that it’s recommended to use “USB Power Blocker” or manually block power from USB cable.

5

I appreciate the reply @gaolst, thanks.

I’ve just ordered an SKR Pico. It looks like a fairly straight forward replacement.

6

Are you using a USB hub between the Host and the MCU?

There seems to be some evidence that certain usb hubs (Single transaction translator or STT) dont play well with klipper, i suspect its related the blocking behavior of these types of hubs and the timing requirements for klipper, especially in multi mcu setups. If you are using a USB hub, try to ensure its the MTT type (Multiple transaction translator).

This resolved my problems in running a setup with 6 USB MCU’s where the EOF error was happening.

@Sineos im not sure if this is something you’ve come across before, if not id be happy to discuss with you.

1 Like
7

Thanks for the pointer. Indeed, there have been one or two occasions where it seemed that this or TTC errors could be attributed to the USB hub.

Generally, it is a difficult topic, since it appears to be related not only to TT capabilities but also to power handling. See RPi Powered USB Hubs - eLinux.org for a quite extensive rundown of this topic. Unfortunately, a lot of the positively tested hubs on this page seem to be EOL.

I’ll think about how to best highlight this in the relevant KB articles.

8

Just my two cents but I discovered long ago to never use an upstream powered (aka “unpowered”) USB hub except for keyboards and mice.

USB 1.x and 2.0 have a current sourcing specification of 500mA and a lot of hubs do not draw more than this to limit the maximum current they can draw from the upstream device (ie laptop). Note that webcams usually draw at least 250mA and can draw as much as 900mA. USB C can source up to 900mA.

Also note that there is a data rate factor involved here. Most unpowered hubs will give you USB 1.1 “Full Speed” (12Mbps) and not USB 2.0’s “High Speed” (480Mbps) or USB 3.0’s “Super Speed”. This means that your webcam can overwhelm the hub, preventing any other communications or not able to keep up with the data stream from a single device.

In terms of what this means from a practical standpoint is that for an unpowered hub can really not power much more than a keyboard and mouse.

If you’re going to attach something like a webcam to your printer:

  1. Make sure you understand how much current it requires. Ideally keep it to less than 500mA and use it on a single rPi USB port.
  2. Make sure that you understand the data rate requirements. I believe most webcams can work with USB 2.0 480Mbps “High Speed” but if you have a 4k camera and want to run at greater than 1080p, you will need USB 3.0.

The rule of thumb should be if you’re adding a webcam, put it on of the Raspberry Pi’s USB 3.0 ports.

If you’re not using a Raspberry Pi, then make sure you understand what the capabilities are of your USB host and the device you’re connecting to it.

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.