MCU Disconnect while print was paused for filament change | Mainsail | Page 1

wanton hazel May 6, 2025, 2:46 AM

#

I have just transferred from using Klipper on a Raspberry Pi 3B to using a Pi 5, i have two klipper instances for my two Ender 3 Max Neo's that are running Mainsail, Moonraker, Crowsnest and Obico, my old setup didnt have obico however. the old one has been printing fine for over a year and when setting up this one i decided to reuse some of the config files (cx_printer, printer, timelapse and crowsnest, with the relevant pathways to files or connections changed of course)
It was printing fine, then i had a nap and woke up to it saying it had lost connection to the MCU while the other printer was still running fine. According to my Obico notifications, it paused for filament runout and then apparently the print 'finished' (im guessing that was when the mcu disconnected) exactly 2 hours apart, Ive added my Klipper and Moonraker logs as well as my Printer cfg and the screenshot of the Obico notifs

Hopefully its just some dumb thing that i had forgotten to add to the config file, i dont really know how to read the logs well so i appreciate the help

📎 klippy_2.log 📎 moonraker.log 📎 printer.cfg

#

And apparently as i was writing this, it also disconnected again while it was sat idle, again with the other instance running fine, here are the klipper and moonraker logs from just now too in case that helps

📎 moonraker_2.log 📎 klippy_4.log

coarse island May 6, 2025, 7:43 AM

#

Traceback (most recent call last):
  File "/home/klipper/klipper/klippy/gcode.py", line 459, in _respond_raw
    os.write(self.fd, (msg+"\n").encode())
BlockingIOError: [Errno 11] Resource temporarily unavailable

this indicates your usb mcu connection was gone.

#

did i get this right? youre using one pi for two printers?

wanton hazel May 6, 2025, 8:19 AM

#

Yes im using one pi that is connected to two separate printers both on their own klipper instance, i also have two cameras connected to it as well, there shouldnt be any issue with the actual usb connection to the boards (as in loose cables or shorted wires) as they are the same cables ive been using for the past year on my old setup

coarse island May 6, 2025, 8:22 AM

#

usb bandwith is quite often a problem. try unpluging the cameras and give it another try.

wanton hazel May 6, 2025, 8:27 AM

#

Ok I will unplug one of them to see how that lasts, it's just weird that my old rpi 3b was able to handle all of it fine yet the rpi 5 can't

storm remnant May 6, 2025, 8:41 AM

#

I got told, depending on the exact usb configuration it's possible that the Pi5 is actually worse.

#

Can you tell me why exactly you switched if everything was working fine and you are now using the same setup? Just curious

wanton hazel May 6, 2025, 8:59 AM

#

I had to compromise with my old one on not being able to use certain features as they took up too much cpu power, such as recording timelapses, i needed a new raspberry pi for another project so i figured id order a pi5 as they were on sale at the time, only just got around to actually setting it up though, i did think about using an old laptop instead but the one i had would have performed worse

#

my plan was to use the pi 5 for my printers and reuse the pi 3b for the other project

wanton hazel May 6, 2025, 9:23 AM

#

Mentioning usb configurations just made me realise something that i hadnt checked, one of my printers is on a 2.0 port and the other is on a 3.0 port (i hadnt thought about checking the USB port versions and just had them in the same order my old one was using) im guessing it might have better chance if the printers are on the 3.0 ports as they would have more bandwidth allocation right?

coarse island May 6, 2025, 9:29 AM

#

the biggest bandwith consumer are the cameras, so seperating them from the printer mcus might be a good idea.

#

the mcus communication needs to flow smoothly since this is time critical but it is not a lot of data.

wanton hazel May 6, 2025, 9:57 AM

#

I will try out a stress test once my current print has finished then, the one that hasn't stopped is on the 3.0 port so it makes sense

storm remnant May 6, 2025, 10:37 AM

#

To be clear, printer should be on 2.0 and cams on 3.0.
The Pi5 should be actually worse than the Pi4 for the Timelapse generation.
The Pi5 has no hw encoder, therefore the timelapse encoding runs on the CPU. But I have to confirm again that timelapse is actually using the hw encoder and not the CPU

storm remnant May 6, 2025, 10:38 AM

#

wanton hazel I will try out a stress test once my current print has finished then, the one th...

So the cam on the 2.0 port most likely uses too much bandwidth causing the printer to timeout. That's why you should put the printer on the 2.0 port and cams on 3.0

wanton hazel May 6, 2025, 11:00 AM

#

Fair enough, i will try that then, thanks ^_^

#MCU Disconnect while print was paused for filament change