Unfortunatly it didn’t work out…
I’ll try different USB-Ports on the Pi.
So what happened? Anything different - does the supply have any kind of display to give you an indication of how much power was provided while it was running?
Can you post your latest klippy.log?
Sorry to hear things didn’t work for you.
I’m not sure what you expect by changing the USB Ports on the rPi.
Going back to the start - I asked for a wiring diagram and you provided me with some photographs of the bottom of your printer. The photographs are helpful but they really don’t show what goes where and how things are connected.
Could you take a few minutes and draw out how everything is wired?
I’m sure we’ll figure out where the problem lies.
Unfortunately I have not saved the last klippy log.
Same error: Lost connection to can0.
I am now trying to connect the Ebb36 directly to the Octopus.
I allready tried to ground the stepper, but could it help to ground the EBB36? And can i use the ground from the can cable or should I use the 24V minus?
24V and 5V is 1,3mm². Groudning is 1.75mm².
Do you need more?
EDIT: also grounded: Frame, Bed, SSR
What do you mean “ground the stepper”? What are you trying to do? The stepper should just have the four wires from the Octopus going into it.
The image is helpful and there is one issue, you have a ground loop:
I suggest that you break the V- connection between the two bulk supplies:
Let’s try to keep the number of variables down to a minimum.
Could you:
- Continue with eliminating the U2C and moving the CAN Bus connection from the U2C to the Octopus board. Once you’ve done that, you’ll follow the Esoterical Guide for Klipper USB to CAN bus bridge
- Break the V- connection noted above. I presume you’re going back to the 200W power supply?
- Don’t do anything else. Don’t ground anything just keep things the way they are.
Once you’ve done that, let us know how things are going.
Please make sure that you are clear in what you are changing so we’re all on the same page.
It comes from my Stealthburner with the SB2240 Toolheadboard, which had problems with static discharges from the extruder stepper. The solution was grounding the motor housing… thought i could give it a try.
Got the octopus flashed and can bus is running. I also removed the V- connection between the PSUs.
Result: Lost communication with MCU ‘can0’ 
klippy(21).log (873.5 KB)
Is maybe the high Bandwidth over 100% a problem?
Thanx for this, the stuff you’re providing is helpful.
I’m looking through the latest klippy log and things start to go bad at 575.4 and the print crashes at 610.4 with a CAN loss of communications. These seems to be after the bed meshing and QGL.
Questions for you:
-
Are you just running from the SSD without an SD Card? Did you recently move to the SSD. I’m asking because SSDs can cause timing problems. Even though they are faster for transferring bursts than an SD Card, SSDs can have times that they don’t respond.
-
How are you holding down your CAN Cable - I think it’s the assembly circled in Yellow, but I want to confirm:
-
Do the failures occur at a specific point in the printer? Is the printer doing anything the same when the error happens?
-
How fast are you running the printer? Have you tried different speeds?
-
Where did you get your
PRINT_STARTmacro code? I’m asking because there are two macros,_status_meshingand_status_cleaningthat are invoked but there is macro code to execute.
Thank you for helping! 
No its mid print. I searched through older klippy logs and its always a diffrent line were it stops.
Yeah, no SD card, only SSD. I have this setup since 2 years.
Yes, its the “PUG” mount wth a self created holder: https://www.printables.com/model/378567-pug-parametric-umbilical-gland
Different points, but always mid print after homing, qgl, meshing etc
This are my “quality” settings I normaly print. I’ll try to print with 50% speed. But i don’t think that will help. Sometimes it crashes while printing the first layer which is pretty slow.
_status_meshing and cleaning is for the nozzle leds. Different colours. I have created the print_start macro by myself.
EDIT: Slow printing didn’t solve the problem.
OK, i think i got it. I deactivated the nozzle LEDs und the case lighting. Now he is happily printing for half an hour. Can the LED effects of the nozzle leds overload the can bus???
That was literally next on my list of questions for you. You have quite a few macros devoted to the LEDs and, when I looked at the latest klippy.log, they’re very active and listed right after the MCU quits:
The short answer is yes but I’ve never seen it in a system with only two NeoPixels. I have seen it in systems with ten or more NeoPixels that were active.
I think if you eliminate the animations (ie “breathing”, “gradient”, etc.) you’ll be able to keep using them without the crashes.
Where did you get those macros? If you didn’t write them yourself you should ask the author if they’ve experienced similar problems or people have reported them back to them.
Let me know how taking out the animations works for you.
The led_effect modification has built quite a reputation for breaking Klipper in creative ways. Toward the end of last year, a few hardening measures were added to make Klipper a bit more resilient against these sorts of self-inflicted denial-of-service “enhancements”.
Still, the prevailing wisdom seems to be:
- Code modifications (a.k.a. “extras”) are completely harmless.
- If Klipper crashes, it’s obviously Klipper’s fault because:
- The extras are harmless.
- The code and the author’s grasp of Klipper’s inner workings are unquestionably flawless.
- Did I mention they’re harmless?
Again, a perfect example, why we should not even start troubleshooting if modifications are installed.
Sincere apologies for the slight sarcasm. I’m trying to keep it to a minimum.
The led_effects are from the this git: https://github.com/julianschill/klipper-led_effect/blob/master/examples/Voron_Stealthburner/stealthburner_led_effects_3_leds.cfg
Had these on my old stealthburner without any problems for more than a year. Maybe the SB2240 is better then the EBB36?!
I also had a high density logo led on my Stealthburner with 25 leds and several effects: https://west3d.com/de-de/products/double-density-rainbow-stealthburner-led-upgrade-overkill-edition?srsltid=AfmBOor_4nc-XVKHRSX3lKZB9zwc_iuQiOY5tQoocxyxeOFt1D9VcvEh
Very weird… But hey, im very happy to be back printing! 
Good to know. This gimmiks has now cost me over €100 and two months of not printing. I’ll switch to light on/off and nothing else…no fancy shenanigance any more.
No problem. I love sarcasm.
I’ve dealt with LED causing a system to crash a couple of times in the and they’re always at the level of “Well, we’ve pulled everything else apart in the printer, let’s try this”.
When I look at the various klippy.log files provided by @Kridi88, there’s nothing that would lead me to jump to looking at the LEDs:
In two of the three logs, the error was caused by “Transition to shutdown state: Heater extruder not heating at expected rate” while the other is “Transition to shutdown state: Lost communication with MCU ‘can0’”.
So, what can we/I do to diagnose LED/NeoPixel problems like this faster?
I approached it as a Power/CAN issue because that’s what I thought I was being told from the klippy.log. In doing research, I found one case where an SDD being used in a rPi caused a TTC shutdown but none with the NeoPixels being the problem.
In the two cases where I suggested looking at the NeoPixels and it turned out to be the problem there was ten or more NeoPixels being addressed constantly. Looking back, I should have recognized that “breathing” and “gradient” should have been investigated but nothing jumps out here that would point to the NeoPixels.
Thoughts on how we could have approached this better/more efficiently?
The issue is not LEDs per se, but the unofficial led_effects.py extra. From the history, it seems:
- Easily allowing effects that starve the bandwidth and/or the CPU.
- Maybe doing so in sensitive Klipper areas or without the needed diligence.
- Leading to hard-to-diagnose issues, from TTC to lost communication, and everything in between.
So, the first early warning is Klipper’s dirty flag and the reference to led_effects.py.
In this case:
- No “dirty” flag in
klippy.log. Something that I always look for first. - Here are the
[includefiles in the postedprinter.cfg:
[include mainsail.cfg]
[include macros.cfg]
[include homing.cfg]
[include canbus.cfg]
[include XOL_leds.cfg]
[include KAMP_Settings.cfg]
[include nozzle_scrub.cfg]
[include caselight.cfg]
– I looked at “caselight.cfg” and there’s no loading of led_effects.py. I’m not sure wat XOL_leds.cfg is, I couldn’t find it in a Google search.
So follow the process we went through here; first look at the usual suspects for lost MCU (CAN) communications and then look for NeoPixel issues?
Log provided in the second post:
Git version: 'v0.13.0-156-gc01e6eee1-dirty'
Untracked files: klippy/extras/autotune_tmc.py, klippy/extras/led_effect.py, klippy/extras/motor_constants.py, klippy/extras/cartographer.py, klippy/extras/idm.py, klippy/extras/scanner.py
Branch: master
Remote: origin
Tracked URL: https://github.com/Klipper3d/klipper.git
CPU: 4 core ?
Python: '3.9.2 (default, Mar 20 2025, 02:07:39) \n[GCC 10.2.1 20210110]'
webhooks client 547501749296: {'program': 'Moonraker', 'version': 'v0.9.3-87-g06cdffa'}
Did not check the further ones.
Huh, it’s not in the last one posted.
Thanx for the information.
For what it is worth, the log does show some symptoms one can look for in the future. The first is that the error always occurs around the same time that host “garbage collection” occurs at - for example:
Timeout with MCU 'can0' (eventtime=1610.162071)
...
Reactor garbage collection: (1609.286370614, 1606.993792042, 1389.07871019)
If the host code is always found to be doing memory management right around the time of the problem it’s a good sign that the problem is something going wrong in the host software.
Another sign of something wrong is that the host software reports a shutdown, but the log does not contain the messages sent to/from the “can0” mcu (nor does it contain messages to/from “scanner” mcu). So, for example, one sees:
MCU 'mcu' shutdown: Command request
But there is no equivalent line containing MCU 'can0' shutdown: Command request (nor one for “scanner”). The fact that the host consistently reports a shutdown, but doesn’t log everything, generally indicates that the host software has become unstable. Admittedly, it’s hard to find clues in missing log entries, but that’s one of the things I noticed.
So, ultimately, in this particular case it looks to me like the host software has become unstable, and the various reported errors were symptoms resulting from that. It is not clear to me why the host software has become unstable. If someone can reproduce the issue on unmodified code I’ll take a look.
If you’ve been searching for the string “dirty”, then as an alternative you could search the log for the string “Git version” instead. I’ve seen a few cases where the version information didn’t make it to the logs - I’m not sure why that is.
Maybe that helps a little,
-Kevin
This is the config for the two nozzle leds with a lot of led_effects in it.
Can I help with this? What do I need to do to make it possible for you to test it?
And thanks to everyone for the help.
This would need reproducing the same unwanted behavior without including any unofficial third-party modifications.
(post deleted by author)