Lost MCU communication

[sywong2000]

Hi guys

I am having the similar problem. Mine print built is a Tronxy Crux 1. Chip is STM32F446. The max print area is 180mm x 180mm x 180mm.

I read that some other people who has similar problem and it only happens when the print covers a large area. That seemed to be similar to what I have experienced. It’s not about the print time, nor speed, complexity, but relevant to the print area.

So I started an experimental print with a simple rectangular prism which is 20mm*20mm*150mm, without extrusion.

When I print it in standing veritical position (150mm at the Z-axis side), the prints completed without problems.

Then I lay the model down and start printing it 150(x)*20(y)*20(z) and the MCU stopped responding in the middle of the print. Same when I do 150mm in (y). If I print with extrusion it will comes with an internal error “G1” stepcompress error. When I print without extrusion it just stopped and saying MCU is offline and the print just freeze at a point.

Then I scale in the slicer (I used Cura) and test for y = 120mm and each time down 30mm and the only working size to complete the print is when y = 60mm

At the X-axis, the print fails when X = 150mm. I am now trying to scale down the prism and print it with 120mm, then 90mm and 60mm.

So at this point, to me, the problem seemed to be relevant to the model size.

I know when we see mcu not responding, the hardware may be something to go looking at - but from my experiment - it seemed that the problem is relevant to the model size at the X and Y axis. And the problem happens every time when the size is big enough particular at X and Y. If I print a thin (under 10mm at axis Z) I may get through. But when Z is high enough it would just stopped somewhere at “random” points. Yet there’re certain pattern and usually it’s stopped at somewhere around 10-20% of the print.

I did turn off some unused service in my RPI4. There’s 4Gb ram so it’s more than enough. CPU is not in high usage too.

I tried enlarging the stepper_y min/max position to a large value (like up to 300mm and -100mm) but it does not work. I’m trying exaggerating the values (to 3000mm and -1000mm) and try again.

uploading klippy log
klippy (4).zip (39.6 KB)

and supplement the dmesg during failure

[ 13.827645] bcmgenet fd580000.ethernet: configuring instance for external RGII (RX delay)
[ 13.828528] bcmgenet fd580000.ethernet end0: Link is Down
[ 18.430701] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 90.935894] Bluetooth: RFCOMM TTY layer initialized
[ 90.935934] Bluetooth: RFCOMM socket layer initialized
[ 90.935961] Bluetooth: RFCOMM ver 1.11
[ 598.034100] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb topped: -32
[ 598.034579] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb topped: -32
[ 598.077714] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.078193] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.105929] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.106552] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.159122] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.159684] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urbstopped: -32
[ 598.239131] usb 1-1.4: USB disconnect, device number 4
[ 598.240268] ch341-uart ttyUSB0: ch341-uart converter now disconnected from tyUSB0
[ 598.240452] ch341 1-1.4:1.0: device disconnected
[ 598.465048] usb 1-1.4: new full-speed USB device number 5 using xhci_hcd
[ 598.571163] usb 1-1.4: New USB device found, idVendor=1a86, idProduct=7523, cdDevice= 2.64
[ 598.571187] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumbe=0
[ 598.571196] usb 1-1.4: Product: USB Serial
[ 598.575808] ch341 1-1.4:1.0: ch341-uart converter detected
[ 598.581366] usb 1-1.4: ch341-uart converter now attached to ttyUSB1

[sywong2000]

After a few tests here’re the results so far:

1. I’ve found there’re two position_min in [stepper_x] and I removed one of them and now it seemed I can print when x = 150mm without problems anymore

2. However I checked [stepper_y], no problems in [stepper_y]. I tried to adjust the values in stepper_y. I’m still unable to print anything beyond 60mm length at the Y axis.

3. I printed a 150mm tall (Z-axis) with at the lower left corner of the plane (where X and Y were both < 50mm) and there’re no problems.

So still somehow when the prints contains a certain amount of long Y axis movements would caused the freeze.

[Sineos]

Your error is not related to the one discussed in this topic. Moved it into a new topic.

See Timeout with MCU / Lost communication with MCU
You have an unstable USB hardware connection, as can be seen in the dmesg output.

[sywong2000]

Thank you. I tried swapping cables, changing with my RPI4 to RPI3, make sure power supply is good and yet no luck. Eventually, turn out my case was the baud rate. I read from other forum suggesting to change the baud from 250000 to 460800. I then redbuild the klipper image and reconfigure in printer.cfg, and the print now be able to be completed successfully. My printer uses CH340 for the USB communication, and FYR:

CH340 supports common baud rate: 50,75,100,110,134.5,150,300,600,900,1200,1800,2400,3600,4800,9600,14400,19200,28800,33600,38400, 56000,57600,76800,115200,128000,153600,230400,460800,921600,1500000,2000000 and so on.