Voron 2.4: Can not update MCU 'mcu' config as it is shutdown

Basic Information:

Printer Model: Voron 2.4 350
MCU / Printerboard: Octopus 1.1, SB2209 with U2C, PI4
klippy.log

Describe your issue:

Ive got Voron 2.4 with Octopus and SB2209 CAN board all connected to PI4, everything seems fine but ive got error in the middle of print as shown in photo attached.


What is the solution for that error? Normally printer is doing everything as normal, it just starts printing after leveling and all that stuff, and after around hour or so it just shut down.
klippy.log (3.4 MB)

See Can not update MCU '<name>' config as it is shutdown

I just restarted and will try to print it one more time.

This is exactly what I reported here Intermittent crashes with no obvious reason - #14 by patrik-zitko but no one, even Kevin helped. It seems to me like some bug related to CAN, as since that I did not had that problem.

@koconnor pls check this, I am not the only one who is suffering this issue.

Not sure that this is the same:

  1. The OT did not provide a log, thus it is not possible to macht against yours
  2. You might have the same error message but since this error message is the consequence of an earlier issue, this cannot be compared at this stage
  3. Your issue looks like an unstable CAN connection. Steps to diagnose can be found here: CANBUS Troubleshooting - Klipper documentation

Now i started printing and got this error:

“MCU ‘EBBCan’ shutdown: Timer too close
This often indicates the host computer is overloaded. Check
for other processes consuming excessive CPU time, high swap
usage, disk errors, overheating, unstable voltage, or
similar system problems on the host computer.
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”

Check our Knowledge Base. Here you will find the common Klipper errors and their typical reasons / solutions.

Edit: And in general, I will stop answering to any request that is not accompanied by a klippy.log as indicated in every new post’s template (which you also ignored in your first post).

1 Like

I just updated my post with the latest Klippy.log file.

The original one was 24MB in size, so I could not upload it. Im never ignoring anything

May I ask you where you found an evidence of unstable CAN? It is printing and suddenly the klipper service restart happen.

Both @Kromka_z_maslem and @patrik-zitko logs contains a lot of

Got error -1 in can write: (105)No buffer space available

So far you both are first ones, where I see this error. So I would guess it is not a common problem, given the fact that CAN usage in Klipper is quite widespread nowadays.

Unfortunately I cannot contribute more than referring to the CAN Troubleshooting document as linked above.

You might also try to increase the queue length, e.g.:

allow-hotplug can0
iface can0 can static
    bitrate 500000
    up ifconfig $IFACE txqueuelen 2048
    post-up /sbin/ip link set up $IFACE type can bitrate 500000
2 Likes

I went through the docs before I made this thread, I would try to update the buffer size with something bigger, but honestly I really don’t know how it could help…

I would really appreciate if I could be able to see at least something in the logs, all we can see is service restart with no exception thrown before it. Even it would be unstable CANbus communication I would expect to see something, uptime of the Pi is not affected, Pi is not reporting throttling event, so the OS could be I hope excluded.

My observation ( @Kromka_z_maslem please confirm / reject ) it happens mostly in first few minutes of print. I.e. I had ~7hrs print which was affected in like first 10s, then maybe after 2 minutes, then it was printed without any error. Same file, just after FIRMWARE_RESTART

So I have some guesses about what is causing this problem. First of all, I know for sure I should reroute my can cable, and I will do it after my print maybe is done. So far, so good. I need to make it shorter and better for me; i have U2C close to hole in bottom :wink: i also disconnected completly toolhead leds, turned all neopixel off completly. My printer stopped pretty much in a kind of random place; yesterday I got two times around 1 hour of printing time, today twice in 30 minutes. Never before. Everything works smoothly, like bed leveling. The adaptive mesh is great; it prints the first layer very well. Everything seems okay until it randomly stops working.

Could you please paste here output of

xx@xx:~ $ ifconfig can0
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 1036353 bytes 7834623 (7.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 115952 bytes 695563 (679.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

In my case the txqueuelen was totally ignored and I found the default is as low as 10.

It was due to dumb typo in /etc/network/interfaces.d/can0 for some reason I had infoconfig instead of ifconfig.

Unsure it is root cause of my issues with print stall but at least explains why I have full buffer so often

Did you fix that issue? If not, hit me up, and ive got solution for this, finally made it work

Would be great to share it here for anyone with the same issue… I personally fixed that by correcting the typo in interface config on OS level.

So first i got new SB2209 board and new PI4, second i installed new PSU just for toolhead, very clean wiring. Got suggestion to type: “sudo ip link sec can0 txqueuelen 1024” than it was showing 1024 but after reset it goes back to 10. so than: “ls -l /etc/network/interfaces.d” showed files can0 and cad0. That means cad0 was interrupting my whole config. After command “sudo rm /etc/network/interfaces.d/cad0” everything started to work finally. Now im happy printing with no errors. Also i experienced error “no buffer size available”. Now ive got very clean klippy.log file. So my setup might looks like overkill, but i think it makes sense.

So basically very similar issue to mine - small buffer set on OS level. Conclusion is if the buffer is very small, klippy service tends to quietly crash.