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:
The CANable USB2CAN board ( https://canable.io/ ). I have this device and it works well. I’m using 1Mbit bus speeds with it and I don’t see any errors.
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.
The UCCB board. I don’t have one, but I’ve heard some people have had trouble with it. Anyone have further data?
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.
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.
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
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 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
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.
I am just starting to build a custom project based on Voron. At the moment I only tested communication between this MCP2515 and a Octopus Pro, though, I will be adding a Ramps 1.6 (Mega2560) and possibly a bunch of Pi Pico and/or ESP32’s. Wondering if you will be adding support for canbus on these…
I don’t believe the 2560 or RP2040 (Pi Pico) have hardware support for CAN, so it’s not possible to use them in a CAN bus. I believe the ESP32 does have hardware support with the addition of a transceiver, but this MCU is not supported in Klipper at all right now.
Problem between Bigtreetech U2C and Octopus Pro 1.0.
The communication over USB/CAN working fine, but interruption during the print happening with 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
I went back to the serial communication between Raspy and Octopus, while maintaining the U2C for the can bus communication to the EBB42. everything working fine , done a lot of prints without any issue
So the problem is in the Can bus over usb from the U2C
“The signal protocol on the USB data cable of this connection mode is still the
TTL level signal of MCU rather than the differential signal of CAN, so the antiinterference ability is not strong. Please avoid using too long data cable and avoid
being close to places with strong signal interference.”
Maybe that is the reason why it does not work properly. Did you try to connect the Octopus via the RJ11 canbus port on PD0/PD1 to the U2C?
Does anyone have any experience with this one? I accidently ordered that instead of the MKS one, since they look very similar. Unfortunately it seems not to be reflashable? At least I found no boot jumper, and it also seems to be gd32 based instead of the stm32.
Ah… I may have interpreted that as a 2 position jumper for resistor on/off, not as boot/resistor… I’ll check that. Even so, is there a firmware for that device? Candlelight only seems to list STM32 devices as supported.
Well… the jumper doesn’t put it into boot mode. It’s literally connected directly to nothing but the termination resistor.
However, I’m at least able to see the EBB36 and even flash it over CAN with it, so hopefully it will work in an actual use case (haven’t set it up with an actual MCU board yet).
After reading the CAN code on MCU side, I can predict that you will have some random transfer errors or package loss issues.