Host CANbus devices

I’m interested in feedback on experiences with host CANbus devices. We’ve recently expanded the CANbus support in Klipper - in particular to make it easier to support communicating with some “toolhead boards”. However, one recurring issue with CANbus support has been identifying good host interfaces.

Some boards I’m aware of:

  1. The CANable USB2CAN board ( ). I have this device and it works well. I’m using 1Mbit bus speeds with it and I don’t see any errors.
  2. The Waveshare CAN hat ( RS485 CAN HAT for Raspberry Pi ). I’ve used this board and it seems okay. It does show periodic drops and it’s probably best to limit it to 500kbit frequency. It connects directly to the raspberry pi gpio headers. It also, unfortunately, has a 120 Ohm resister on the adapter that can not be easily disabled.
  3. The UCCB board. I don’t have one, but I’ve heard some people have had trouble with it. Anyone have further data?
  4. Adding a CAN transceiver to the beaglebone board. I’ve heard this works well, but it only works on the older Beaglebone boards, which are a little slow for running the host software.
  5. The Innomaker USB2CAN adapter. This board does not work well. I have one and it is nearly unusable. It appears to have firmware that reorders CAN packets, and worse, it appears the firmware is locked down so that it is not possible to fix the problem.
  6. Other boards?

Let me know if you are aware of other boards and your experience with them.


I’m currently use this SBC-CAN01 Breakout-Board for my testing setup. it works well uses the same Hardware as the RS485 CAN HAT for Raspberry Pi (MCP2515 and MCP2562). Did not test more than 500kbit/s. It has a 120 ohm resistor, that can disabled with a Jumper

Please help me with the CAN settings. I don’t know what I’m doing wrong.
klippy.log (3.5 KB)

Is it Possible to use Klipper with a Can adapter and a Duett Toolboard LC1 ?

Or is it possible to use the can adapter of a MCU ? for example from a duet or a spider board ?

I’m using the UCCB with my Huvud on a Voron Switchwire. They recently released a binary that includes the queue fix from the candlelight firmware. I only have about 10 hours of print time on this new printer (and I’m running the multi-mcu branch), but I’ve had no problems with the UCCB running this firmware. I did have some trouble flashing the board, and I had to resort to STM32CubeProg on a Windows machine.

Hi, I’m new on Klipper, but not so new on CANbus :slight_smile: After reading the CAN code on MCU side, I can predict that you will have some random transfer errors or package loss issues.

This part of code assumes, that all packets send will reach the linux user space application and all of them will be in the same order: klipper/canbus.c at master · KevinOConnor/klipper · GitHub
There is a big chance that “Waveshare Raspberry Pi CAN hat” will loose some of packets on heavy CANbus load and/or have host CPU load. There is also some chance, depending on the kernel version, that some packets will be out of order.
It is recommended to use some protocol on top of CAN bus, which was design to transfer anything more then 8 bytes. As kernel J1939/ISObus maintainer, I would recommend to use this protocol :slight_smile:

Yes - we see drops on the waveshare board. We don’t see reorders in practice. Note that the Klipper message protocol has sequence numbers, a CRC check, and retransmits ( Protocol - Klipper documentation ). So, sporadic corruptions at the lower level shouldn’t be an issue (though reorders would not be great).

Using a higher level protocol on CAN is possible. However, the CAN protocol is already very heavy weight with headers - about half the theoretical bandwidth is lost to existing headers. Adding even more headers to every packet would not be desirable.