MCU 'EBB' shutdown: Timer too close with error “Got error -1 in can write: (105)No buffer space available”

General Discussion
1

Basic Information:

Printer Model: Voron Trident
MCU / Printerboard: Octopus 1.1, U2C 2.1, EBB36 1.2
Host / SBC Orange Pi 3 Lts
klippy.zip (2.2 MB)

I start printing the model and it keeps stopping at the same place with this error:

image
image649×566 35.6 KB

I see the following lines in the logs:
“Got error -1 in can write: (105)No buffer space available”
Any ideas on how to fix it? Thanks.

2

Your log is showing that your canbus is constantly experiencing that error (No buffer space).

This means that klipper did put data in canbus - but they was not sended because of some short issues, eventually they stuck for soo long - that you get ‘Timer too close’ error.

Check canbus wiring as described here: CANBUS Troubleshooting - Klipper documentation

As an option try to increase canbus speed to 1000000 if it have less speed, then try to increase txqueuelength for canbus.

3

This is almost always a wiring issue, I was just dealing with the same thing. Check all your connections and your crimps to make sure they’re all making good connections.

If the connection is flaky the data gets stuck in the buffer until it fills up and throws this error.

4

All my connections and wiring I checked twice.

I find this:https://github.com/linux-can/can-utils/issues/262

Ifconfig command returns can0 txqueuelen 10,

but, txqueuelength in /etc/network/interfaces.d/can0

allow-hotplug can0
iface can0 can static
    bitrate 500000
    up ifconfig $IFACE txqueuelen 128

I dont know why ifconfig returns another value.

I use the command:

ifconfig can0 txqueuelen 1000

and it fixes my issue.

5

I have same issue, I have set txqueuelen to 1024 in /etc/network/interfaces.d/can0 but that’s no guarantee it will not default back to 10, I have no idea why but it does.

Running: ip -det link show can0 directly after manually setting it always displays 1024, however, some time later, the same command now shows 10.

For example, during several test sessions over the space of several days, I checked it and only on one occasion was it set to 1024, every other time it had defaulted to 10.

After reading this post, I will go back and see if buffer has once again defaulted to 10, it might be my issue…

Update, it had… set it manually and tried printing again… too early to say but it looks like that was the issue as print has already gone far beyond where it errored out on the last four occasions… Now at 15%, would bet that’s it fixed…

So, it appears txqueuelen defaults back to 10 after a reboot/power-up and settings in …interfaces.d/can0 are ignored…

That’s a problem, but as it only relates to those who use CANBus, I guess that’s why this issue hasn’t been discussed more often.

6

On a recent systemd based Linux distribution, you should be able to do:

sudo nano /etc/systemd/network/80-can.network

Copy and paste into this file:

[Match]
Name=can*

[CAN]
BitRate=1000000
TransmitQueueLength=128

Should get activated with:

sudo systemctl restart systemd-networkd
7

No luck, created the file with the contents, restarted network but still ip -det link show can0 reports buffer size of 10, even tried a reboot :frowning:

Think I found a solution but need to reboot a few times and see if 1024 persists…

This worked for me…

Created file:

sudo nano /etc/udev/rules.d/99-persistent-network.rules

Add this line:

SUBSYSTEM=="net", ACTION=="change|add", KERNEL=="can0" ATTR{tx_queue_len}="1024"

I’m no expert so best wait to see if anyone has an issue with this method. I have booted several time and buffer size of 1024 persists. I assume if the file already exists, it should be safe to add the line to it…

I found this on github

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.