Printer Model: VZBot
MCU / Printerboard: BTT Pico with BTT EBB v.1.3 CANBUS
klippy.log
klippy-vzbot(2).log (2.9 MB)
ISSUE:
Prints randomly crashing with no obvious reason and / or warning/error. I made many HW upgrades + switched to CANBUS recetly. Klipper update was part of the changes. RPI 3B+ is hosting 3 instances, others seems to be not impacted at all - however not printed lot on other instances to fully confirm.
You have at least many of the following errors in your log:
Got error -1 in can write: (105)No buffer space available
If I’m not wrong this could be a too small buffer of the CANbus device.
How does that files content look:
/etc/network/interfaces.d/can0 ?
Hm, strange I did not recognized that. You are totally right.
my /etc/network/interfaces.d/can0 is
allow-hotplug can0
iface can0 can static
bitrate 500000
up infoconfig $IFACE txqueuelen 1024
Just FYI I recompiled the MCU with v0.11.0-266-g261efdd8 to match with host and set speed to 1000000 everywhere - I can see no buffer errors anymore, but the issue is still with me.
Can you please delete the current klippy.log so a new one will be created and then just try recreating the issues and upload the new log.
Keep an eye on the load of the RasPi 3B+ as well.
Your config states an quite high upper speed limit and 64 microsteps on the motor drivers.
How fast are you actually printing when the crash occurs?
Maybe it is too fast for the hardware somehow.
But I had always other restarts (timer too close if I remember correctly) when this was the fact during testing.
Maybe others have good tips here.
It varies, sometimes it is during travel (where I would expect overload)
Mechanics is capable of speeds over 1000 but the HW is not. If HW overload happens, usual error was ‘timer too close’
Would definitely need someones deep knowledge
Really noone nothing? Today it crashed again - and again nothing in the logs, the service just silently crashed. Maybe Kevin pls, if you could check that or guide me what else can I check? @koconnor
For better understanding: HW stands for? HardWare?
For better understanding: HW stands for? HardWare?
Hi Eddy, yep, HW (in this context) means BTT Pico. It just cant handle speeds over 900 with such microstepping
In your first post you mentioned the BTT Pico.
Similar like this?
It was actually mentioned here. I had typo in the config (see infoconfig), so txqueuelen was not applied.
Since corrected, no stall happened. I would say, there is still bug in the code, when queue is full - log did not say anything before crash.
Anyway if I was the only who hit this corner-case, I will close this one.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
