search

Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.29k stars 5.28k forks source link

MCU 'mcu' shutdown: No next step #3987

Closed Kuenstler79 closed 3 years ago

Kuenstler79 commented 3 years ago

Hello,

during printing I recently get the error "MCU 'mcu' shutdown: No next step - This is generally indicative of an intermittent communication failure between micro-controller and host." more often and printing stops at that point. Most recently, the error occurred when I wanted to print a vase in vase mode (Slicer Cura 4.8.0). I have not changed anything in the wiring. I have the feeling that the problem only occurs since I activated the Input Shaper. (Input Shaper is active, Pressure Advance is deactivated.)

I don't use Klipper under OctoPrint, but have MainsailOS installed on a Raspberry Pi 3.

I am grateful for any help!

moonraker.log klippy.log

Kuenstler79 commented 3 years ago

And again the same error... I had regenerated the GCode, but still the printing stops after approx. 1 hour with the shutdown. The log file is now much bigger, almost 5MB.

Spiral_Vase_CURA_2.gcode.zip moonraker.log klippy.log

Kuenstler79 commented 3 years ago

OK, I printed the same GCode again without an active input shaper. In this case, the shutdown also occurred, but only after more than 5 hours.

klippy.log moonraker.log

KevinOConnor commented 3 years ago

Unfortunately, something on your host computer is using a significant amount of cpu resources. Whatever that is, it is starving the Klipper host process of cpu time - in the first log klipper didn't get cpu time for 7 seconds, and in the second log klipper didn't get cpu time for 3 seconds. Unfortunately, the log doesn't indicate what external process on the system is consuming that cpu time.

Here's a chart of the system stats from the first log (note that the Klipper process time is not increasing so is unlikely the root cause of the problem): log1 And the second log: log2

Info on generating the above graphs is in docs/Debugging.md

-Kevin

Kuenstler79 commented 3 years ago

Hello Kevin,

Thank you very much for the analysis! Do you have any idea what process it could have been? I installed extra Mainsail OS because it is so nicely stripped down. Or is there a way to add more information to the klippy.log? E.g. which processes are running in the background and what cpu load they cause.

Peter

BlackStump commented 3 years ago

I am only a Linux noob but you might want to use htop and see what processes are running. Linux issue. Do you have a Webcam! installed , doubtful it would be the base install of Mainsail OS

Kuenstler79 commented 3 years ago

I am also a complete Linux noob, but "htop" I will give a try. Thanks for the tip! I have a webcam installed of course (via the Raspberry Pi Camera port). I find that essential for printer monitoring. Do you think this could be a general problem? Or the way Mainsail embeds the camera?

Arksine commented 3 years ago

I don't think that Moonraker would cause this (I haven't observed it at least), generally its CPU usage is very low. To be sure I will look into tracking and reporting Moonraker's usage statistics. Kevin, do you think it would it be beneficial for Webhooks clients to report usage statistics back to Klipper, then have Klipper add this info to "statistics"?

I do think that there is a possibility that the Webcam is causing an issue here.

Kuenstler79 commented 3 years ago

Yes, I don't want to rule out the possibility that it could be the webcam. Every now and then it also jerks in the video stream.

One idea could be to integrate a switch in the user interface (MainSail or Fluidd) to turn off the webcam for particularly important prints. Or perhaps show a task manager that you can still counteract and kill an unimportant task.

OK I know, I would have to place the feature request rather with the operating system colleagues...

Kuenstler79 commented 3 years ago

The shutdown issue has been occurring more and more frequently over the past few days. Unfortunately, with "htop" I could not find out exactly which task grabbed all the processor load. In any case, "mjpeg_streamer" and "nginx" were always on top.

I just switched to fluiddPi and fluidd. And, oh wonder, no more problems since then. I don't know if it's the operating system in general or just the fact that I set up the system again.

The high priority processes are now always "klippy" or "moonraker". "nginx" and "mjpeg_streamer" are of course still active, but never on the top places to see.

Ticket can be closed from my point of view.