I recently changed printer board and toolhead from Fysetc Catalyst to BTT SKR Pico.
After successfully configuring Klipper for a CAN bus toolhead and completing several short prints for bed leveling and filament flow calibration, I’m encountering a significant issue with longer print jobs (1 ~ 2 hours). Klipper shuts down with the error message: Missed scheduling of next digital out event. This has occurred twice under similar circumstances.
Here’s the sequence of events for both shutdowns:
Start a 2-hour print job.
The first shutdown occurs at timestamp 5195 with the above error message.
After halting the host and power cycling, I started another 2-hour print job.
The second shutdown occurs at timestamp 7019, with the same error message.
I found the printer down and retrieved the klippy.log files.
My initial suspicion was a CAN bus error due to wiring or noise. However, ip -s link show can0 shows 0 errors, which suggests that the physical CAN bus connection may not be at fault.
Also, from the receive queue dump at the second shutdown, I noticed the following:
(MCU 'can0' refers EBB36 toolhead board)
MCU 'can0' shutdown: Missed scheduling of next digital out event
...
Dumping serial stats: bytes_write=7994550 bytes_read=1713573 bytes_retransmit=2885 bytes_invalid=10116 send_seq=144990 receive_seq=144987 retransmit_seq=144990 srtt=0.014 rttvar=0.012 rto=4.094 ready_bytes=29 upcoming_bytes=2460
Dumping send queue 100 messages
...
Dumping receive queue 100 messages
...
Receive: 99 7019.330052 0.000000 12: seq: 1b, shutdown clock=2832949257 static_string_id=Missed scheduling of next digital out event
This leads me to question if the EBB36(toolhead board) is shutting down and sending the message ‘Missed scheduling of next digital out event’ over the CAN bus.
I am looking for insights into the following:
What could be causing the Missed scheduling of next digital out event error in longer print jobs?
Is this indicative of a problem with the toolhead board, Klipper configuration, or something else?
Are there any known issues or settings adjustments I should consider for stable long-duration prints with this setup?
Any guidance or similar experiences shared would be immensely helpful!
First things first, all MCUs have the latest Klipper version flashed: v0.12.0-115-gb98375b3
Did you make the can-cable by yourself or is it some pre-made cable?
Besides the main error your have some additional ones throughout the klippy.log:
b'Got error -1 in can write: (105)No buffer space available'
b'Halting reads due to CAN write errors.'
How fast are you printing?
You have 15k acceleration and upper speed limit of 1000 mm/s set but the RasPi Zero 2 W is not the fastest SBC out there.
How does your /etc/network/interfaces.d/can0 config file look like?
The above errors look like the canbus buffer is too small or you are too fast for it.
My v0-S1 gets an EBB36 as well but with USB-C connection to avoid such topics.
Currently it is running with the Picobilical stuff.
I contemplated using a USB connection for the toolhead board. However, concerns arose after someone mentioned that a poor ground contact could damage the USB component of the SBC
22 AWG might be a bit thin at least for the power cables. Most say you should use at least 20 AWG or even 18 AWG for the power cables but are good to go with 24 AWG for the data lines.
OK speed wise you are fine and the RPI Zero 2 W should handle this.
Before maybe checking lower bitrate you want to try increasing the buffer to 1024.
Yes you’re right. I will definitely change the power cables to 20 AWG or thicker.
Before maybe checking lower bitrate you want to try increasing the buffer to 1024.
As you suggested I tried the following settings.
1M bitrate, buffer level 1024
Can’t complete 2h print job. It shut downs like before
500k bitrate, buffer level 1024
Work flawlessly.
I have a feeling that high CAN bus data rate might disrupt the time-sensitive operations on the toolhead board, even though the current CPU load on the toolhead board is below 5%. Just my thought.
Maybe due to interferences or other noise the high bandwidth does not work.
If you rewire your power cables maybe you can cut the whole canbus cable to length to avoid that large loop on your photo, decreasing the effective area/wire that can be influenced by interference and stuff like that.
My USB-connection to the EBB36 seems to work now at least in idle mode but I dumbass did not twist the data lines… Hope it will be stable though.
