Klipper Load issues

Basic Information:

Printer Model: Zero G Mercury
MCU / Printerboard: Manta M8p
MMU: BTT MMB 1.0
Filter MCU: Nevermore Mini & Stealthmax PCB by isiks.tech
Host / SBC: CB1
Canbus speed 1mil if i remeber
klippy.log (5.5 MB)
image

Describe your issue:

I am having Klipper load issues and Canbus Issues. usually at idle the printer is fine. sometimes when i try to home the mmu or gantry it will have an error usually related to canbus communication loss and th error says its a possible load issue. i also sometimes have i2c timeouts as well from the filter. i dont know if lowering the speed will fix my issue im curious on your thoughts.

It’s most likely you wiring.

Check your crimping in the connectors as well as how they come together.

When the printer is idle, tug at your wires and pull them back and forth to see if you can replicate the issues and track them down.

Good luck!

1 Like

This worked for another with CAN bus issues but should also work for i2c.

Redo your connectors, then use hot glue on the end of the connector where the wires are inserted to lock them in place. Also, anchor the wires close to the connector to keep them from moving.

I believe i have checked this in the past but have had no issue. i also double checked it but it is fine. but while printing my klipper load is 80 percent average maybe somewhat lower. but there are a lot of spikes into the 150-180% and sometimes i have seen more.

This sounds like some macros or 3rd party extension is producing a lot of stuff like regularly issuing M106 commands or querying temperatures etc.

This load is way too high for Klipper running under normal conditions.

1 Like

i am running happy hare. but i figure a lot of people are using it so im lost as to what might cause it.

If you use unshielded wires for your CAN bus and i2C, failed transmissions can cause those buses to resend and consume processing cycles.

For unshielded; try not to run them near the stepper, bed heater, or hotend wiring; the frequency of PWM signals can be introduced into the CAN bus and i2C bus. Even though fans are controlled by PWM these have less energy use so less of a magnetic field on the wires so less chance of interference.

Could you post some pictures of your printer and the CAN wiring (with connectors)?

1 Like

my tool head wire

my wire to my stealth max

wire for mmu is btt wire

and im also using some of this.





1 Like

Wiring looks good - thanx for the images.

There are quite some report that HH is prone to be causing such errors. In particular, this seems true for the LED control of HH

i do not have leds setup for happy hare since im running a tradrack. i do have an encoder though. maybe its trying to use the commands though ill look through the leds config sections to see.

LEDS not defined so shouldnt call anything.

i turned the printer on today and went to home the mmu and got this error

klippy.log (1.2 MB)

As previously stated: There are several reports that HH is either outright causing such errors or in the best case fostering them.

If it is still the case or improvements have been made etc is beyond my knowledge and such reports only will get further attention if validated that a pristine Klipper is showing the same symptoms and equally validated that it is not caused by the well known TTC reasons.

1 Like

so i should be posting where they can answer questions?

The first place:

You are, @Sineos is one of the best resources on Klipper.

1 Like

what help is this? just posting the link for the happy hare github?

i ment posting where the creator of happy hare could answer.