search

moggieuk / Happy-Hare

MMU software driver for Klipper (ERCF, Tradrack, Prusa)
GNU General Public License v3.0
448 stars 107 forks source link

MCU Shutdown after event on HH (Runout, empty gate, etc..) #359

Open jmceara opened 1 month ago

jmceara commented 1 month ago

Hi! I'm having this problem a while now. After some 'fault' event on HH (filament Runout, gate empty, etc..), my systems starts an MCU shutdown in all MCU's, usually starting by EBBCan (toolhead MCU). I already tried with latest version of debian (bookworm 64bits) + kiauth, tried with 3 new SD cards from different brands, tried siabling almost everything that is not essential (like KliperScreen and my Nevermore StealthMax Controller), still getting the same problem.... The only thing in 'commom' between all MCU Shutdowns is that I had a runout on HH just before the shutdown ( can see in logs).

For this last test, I was using mainsail os 32bits image from january 20.....I was trying to avoid new kernel or module packages that may be causing this error in klipper......but it didn't helped, still getting MCU shutdown when runout or gate empty is detected by HH.

My system setup:

Logs.zip

moggieuk commented 1 month ago

The root cause of the error is a communication issue with the EBBCan. See:

Lost communication with MCU 'EBBCan'
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

There is not much I can do about a fundamental klipper like this.. The code is simply running:

M83

Is it possible you have a loose wire? or incorrect termination of bus? TBH I keep hearing of communication issues with CANbus and generally get the feeling it isn't as reliable as USB.

jmceara commented 1 month ago

The root cause of the error is a communication issue with the EBBCan. See:

Lost communication with MCU 'EBBCan'
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

There is not much I can do about a fundamental klipper like this.. The code is simply running:

M83

Is it possible you have a loose wire? or incorrect termination of bus? TBH I keep hearing of communication issues with CANbus and generally get the feeling it isn't as reliable as USB.

Yep, except that I have exactly the same problem with all MCU's in USB mode (and NO can board). Is this log, I'm using CAN again, but I did tested with all boards in USB mode and no CAN, got the same problem. The only thing that's not quite clear to me is how to trigger this problem, because I just finished an 5h printing without problem.

Just to be clear: I had this problem for a while and a lot of failures, all of them with one common thing: the error (MCU shutdown) always came after an event from HH (in this case, an runout from binky, but I also had problems after an empty gate). I'm not sure whats is causing this, since, like I said, I just finished one printing without issues (and I had one runout again).

I'm doing some more test prints....if I still getting errors, will post here.

moggieuk commented 1 month ago

Ok. Thanks for the extra clues.. the more you observe into what is happening just before, the easier it will be to see if there is something that can be done. As I said, loosing communication is a very low level klipper issue .. I can read the klipper code and see what conditions could cause this.

Note also that the "after a runout event" could be a red-herring... it is possible that communication is impeded, and that falsely triggers the runout (absence of encoder messages will do this) then real klipper error where it concludes it lost connection.

Curious... did the successful 5h print occur after a rpi reboot?

jmceara commented 1 month ago

Ok. Thanks for the extra clues.. the more you observe into what is happening just before, the easier it will be to see if there is something that can be done. As I said, loosing communication is a very low level klipper issue .. I can read the klipper code and see what conditions could cause this.

Note also that the "after a runout event" could be a red-herring... it is possible that communication is impeded, and that falsely triggers the runout (absence of encoder messages will do this) then real klipper error where it concludes it lost connection.

Curious... did the successful 5h print occur after a rpi reboot?

Reboot after error? Is so, yes, I did reboot after error.....then, I made another 3 prints (all successfull) without rebooting pi/controller, just printing. Until now, everything is working. (I hope it keeps this way!)

moggieuk commented 1 month ago

Hmmm. Keep me posted. Note that loss of communication / TTC / etc are all catch-all errors in klipper. They are more likely to occur when doing intensive operations and homing moves are one of those cases. Technically it is what klipper refers to as a "drip" move. Loading and Unloading the extruder or parking in the gate all employ homing moves so if there is a trigger that is likely to be where.