The Basics of CAN Bus: A Beginner’s Guide to Understanding the CAN Protocol – Part 1

The communication protocol, CAN bus, is used in various industries such as automotive, medical, and industrial systems. In the field of 3D printing, CAN bus has the potential to improve the printing process by connecting several components, including the main control board, extruders, and motors. CAN bususes high-speed serial communication to enable real-time communication, making it suitable for applications that require timing and synchronization.

The CAN protocol defines the way devices communicate over a CAN busnetwork, determining how data is transmitted and received, and how devices are addressed and identified. The protocol uses differential signaling to send data through two wires with equal and opposite voltage levels. The protocol can detect and correct transmission errors, ensuring reliable data transmission in noisy environments and over long distances.

Some Hardware Examples:

Main Controller Boards:

  • BigTreeTech(BTT) Octopus
  • Duet3D Main Board 6HC
  • Duet3D Main Board 6XD


  • Duet 3 Tool Board 1LC
  • Duet 3 Tool Board 1HCL
  • BigTreeTech(BTT) EBB36 & EEB42 (Note: certain hardware versions may cause a fire, reach out to BTT support)
  • BigTreeTech(BTT) EBB U2C


  • Duet 3 Expansion Board 3HC
  • Duet 3 Expansion Board 1XD

Once at least 2 CAN bus compatible components had been bought, the process of connecting them via the CAN bus network can begin. CAN bus cables are required to link all components together. Typically, these cables have four wires – two for power and two for communication. One can either purchase these cables or create them using CAT3 or higher-rated cables for the communication wires and appropriate AWG-gauge wires for the power wires if they choose to make them themselves.

After connecting the components, one needs to configure the firmware of the 3D printer to use CAN bus. This involves setting the correct baud rate, addressing scheme, and other parameters to ensure that the components can communicate effectively. Finally, one needs to test their setup to ensure that CAN bus communication is working correctly. This will involve sending commands to the printer and monitoring the responses to ensure that data is being transmitted accurately and reliably.

In case issues arise, some common issues that may occur include incorrect wiring, electrical noise, and software issues. Some resolutions to these issues, double-check all connections to ensure they are properly wired, reduce electrical noise by using shielded cables and ferrite beads, ensure the latest firmware is being used with all settings correctly configured, and ensuring correct resistance & voltage is used on CAN bus.

CAN bus enables fast and reliable communication between different components, allowing for greater control and precision in the printing process, resulting in higher-quality prints. Although implementing CAN bus in 3D printing may require additional hardware and configuration, the benefits are clear. By reducing the number of cables and simplifying the wiring of the printer, one can achieve faster printing speeds, possibly less toolhead weight, and improved reliability. Moreover, using CAN bus in 3D printing allows for scalability and expand-ability, which can accommodate future changes without requiring significant modifications to the network.

Part 2 will cover setup of a BTT Octopus and BTT EBB42 without BTT U2C….

Klipper – Input Shaper w/ Arduino Nano

Want to setup Klipper’s input shaper, but don’t have a Raspberry Pi Pico on hand for a separate Klipper MCU? This article will step through using an Arduino Nano instead. A separate Klipper MCU in this context would allow you to run input shaper on multiple 3D printers by USB without requiring a dedicated ADXL345 sensor on each printer and reducing costs.


Solder these pins together.

ADXL345Arduino Nano


Connect the Arduino Nano to the Klipper Host, in our case a Raspberry Pi 4. In order for us to flash the Arduino Nano from our Raspberry Pi 4. At this time of writing, there is a bug in avrdude used to flash and we will need to add a previous APT repo.

  1. sudo nano /etc/apt/sources.list
  2. Add deb buster main contrib non-free rpi
  3. Save and quit (:wq)
  4. sudo nano /etc/apt/preferences.d/avr-buster
  5. Type below and save file
    Package: avr-libc avrdud binutils-avr gcc-avr
    Pin: release n=buster
    Pin-Priority: 1001
  6. Save and quit (:wq)
  7. sudo apt update
    sudo apt install avr-libc avrdude binutils-avr gcc-avr
  8. cd ~/klipper
  9. make menuconfig
  10. Change Micro-controller Architecture to Atmega AVR and Processor model to atmega328p
  11. Press q and y
  12. make clean
  13. avrdude -patmega328p -c arduino  -b 57600 -P /dev/ttyUSB1 -v  -D -Uflash:w:out/klipper.elf.hex:i
    Note: /dev/ttyUSB1 may be different on your system and per printer primary MCU. Change any reference to match further ahead.
  14. Once this is completed, nano will be ready to be used as a Second Klipper MCU

Update 8/31/2023: For those whom wish to copy and paste into a terminal:

Steps 1-7 – Revert to older avrdude. Note: we didn’t test the newer version and may be fixed.

sudo sed -i '$ a\deb buster main contrib non-free rpi' /etc/apt/sources.list

echo -e "Package: avr-libc avrdude binutils-avr gcc-avr\nPin: release n=buster\nPin-Priority: 1001" | sudo tee /etc/apt/preferences.d/avr-buster > /dev/null

sudo apt update

sudo apt install avr-libc avrdude binutils-avr gcc-avr

Steps 8-13

cd ~/klipper
make menuconfig
make clean
avrdude -patmega328p -c arduino  -b 57600 -P /dev/ttyUSB1 -v  -D -Uflash:w:out/klipper.elf.hex:i

Klipper Config

  1. Add a config file called adxl.cfg under the Klipper config section for each printer.
  2. Add the following lines:
[mcu arduino_nano_adxl]
serial: /dev/ttyUSB1

cs_pin: arduino_nano_adxl:PB2

accel_chip: adxl345
  1. Press save & close
  2. Add [include adxl.cfg] to printer.cfg
    Note: if it is not connected to the printer add a # in front of it to disable
  3. Press save & restart

UniFi – Log4j Vulnerability Notice

Update: 15 December 2021 – version 6.5.54 and earlier is vulnerable. Please update Unifi Controller again.

With the recent Log4j vulnerability, CVE-2021-442228, UniFi controller version 6.5.54 and earlier is vulnerable.

Jacobalberty has backported the fix to v6.0.45 and v5.14.23 for those whom are on the older hardware or controller versions.

For ours, we will be migrating to the latest v6 build by changing out Docker tag to “jacobalerty/unifi:v6” instead of “jacobalerty/unifi:stable-6” by following UniFi Controller – Docker Tag Change again with the tag changed.


Nate15329's Blog