Setting Up udev rules for multiple canbus interfaces

[Sineos]

Thanks a lot work working on this @willpuckett

FWIW, I was more thinking of a concise introduction to the CAN topic that explains the basics of CAN and how it can be used in Klipper.

Something along the lines of:

Table of Contents

1. The Control Area Network (CAN) Bus
   1.1. Pros and Cons of CAN in 3D Printer
   1.2 General CAN Concept
   1.3 General Wiring of the CAN Bus for a 3D Printer
2. Klipper Architectures with CAN
   2.1 Standalone CAN
   2.2 USB to CAN Bridge
3. Configuring Klipper for the different Architectures

1. The Control Area Network (CAN) Bus

The Control Area Network (CAN) bus is a serial bus protocol. All nodes connected to this bus system are able to exchange data between them. Originally, it has been developed for the automotive sector to simplify the complexity of a car’s electronics and the need for information exchange. Since then, this bus protocol has been adopted into various contexts due to its robustness and simplicity.
One of these new contexts is its use for connecting various peripherals of a 3D printer system in Klipper.

1.1. Pros and Cons of CAN in 3D Printer

Pros:

• Simplifies wiring, e.g. all wires that would typically lead to the tool-head are replaced by 2 wires for the CAN bus plus 2 wires for power supply.
• Especially suited for scenarios where wiring is difficult (space constraints) or the cable is subject to constant moving and bending, e.g. on a tool-head. Regular USB cables do not take this type of strain very well.
• Easily extensible.

Cons:

• Adds additional setup complexity. Often it is easier to just plug-in another USB board.
• Adds additional points of failure.

Other:

• Not suited if used within heated chambers, at least if the temperature rises above around 80°C - 100°C. This is not a limitation of the CAN bus itself, but rather of the additional electronic components that are often not rated for these temperatures.

1.2 General CAN Concept

The above schematic shows the general layout of a CAN bus system:

• Data is transferred via two wires (and GND, which is omitted for simplicity). These two lines are called CAN H and CAN L.
• Each participant to the bus is called a Node.
• The “pure” CAN does not foresee means to identify devices on the bus. Klipper introduces a Universally Unique Identifier (UUID) to unequivocally identify the nodes on the bus. This UUID is also used in the printer.cfg to address the respective node.
• All Nodes on a bus are equal, there is no “master controller” or central management device
• The Nodes internally consist of 3 different function blocks. Two of them are typically implemented in a Micro Controller Unit (MCU):
  • CAN Software: The MCU is running a CAN-aware software or application. It manages the information that is either received from the bus or to be sent over the bus. In the context here, this is the Klipper firmware.
  • CAN Hardware: Many modern MCUs have an integrated function block to handle the CAN protocol. One exception is the RP2040, since the RP2040 lacks this block in its hardware. Here this functionality is implemented in software using the can2040 software (No user interaction is needed, Klipper installs this software automatically).
  • Transceiver: This is a separate chip. On the one side, this transceiver connects directly to the bus and manages TRANSmitting and reCEIVING of data packets on the bus. On the other side, it connects to a CAN Hardware block that is implemented in the Micro Controller Unit (MCU)
• To prevent reflections and ringing on the bus, the start and end of the bus are terminated with 120 Ω resistors. The resistors also make sure that the CAN lines are pulled to the correct state.The correct termination is of key importance for a working CAN bus.

1.3 General Wiring of the CAN Bus for a 3D Printer

Depending on the data rate, the length of a CAN bus can reach up to 500m and still up to ~40m for 1 Mbit/s data rates that are typically used in Klipper. As a 3D printer normally uses significantly shorter bus lengths, the mandatory requirements are quite relaxed.

Mandatory Requirements:

• The bus needs to be properly terminated on both ends with 120 Ω resistors. Typically, this is done on the first and last CAN device by setting appropriate jumpers in the hardware.
• As with every other connection, it must have solid contact, especially on crimped connectors.
• On moving cables, the cables should have a quality that allows for continuous bending. This does not necessarily mean that one needs to use drag-chain certified cables.

Optional:

• The applicable standards require cables with twisted pairs.
• Using high-end, shielded, twisted pair, and drag-chain certified cables is the optimal solution, although it may also be an inefficient use of money.
• The default topology for CAN is a linear bus from one device to the next. A star topology is possible, but may introduce additional challenges and hardware requirements. This is beyond the scope of this article.

2. Klipper Architectures with CAN

In the setup and the configuration, Klipper differentiates between two types of CAN architecture

1. CAN Nodes (e.g. tool-boards) connected to a standalone CAN Adapter Module
2. CAN Nodes connected to a CAN-enabled “master printer board”, the so-called CAN to USB Bridge

2.1 Standalone CAN

Description:

• A CAN Adapter Module is connected via USB to the SBC and is the “start” of the CAN bus
  • This adapter needs to be terminated to the 120 Ω by setting respective jumpers on it
  • From this adapter, two wires (CAN H and CAN L) will start the CAN bus
• One or multiple further CAN boards, e.g. tool-boards, are connected to this adapter
  • The boards “in the middle” of the CAN bus must not be terminated
  • The last board at the end of the CAN bus must be terminated to the 120 Ω by setting respective jumpers on it
• Another printer board that supplies the rest of the printer’s hardware is traditionally connected via USB to the SBC
• Not shown: The printer board and all the CAN boards need a connection to the main power supply unit of the printer

2.2 USB to CAN Bridge

Description:

• A CAN-enabled “master printer board” with a dedicated CAN connector is connected via USB to the SBC.
• This “master printer board” supplies the most printer peripherals but also serves as the starting point of a CAN bus.
  • From its CAN connector, two wires (CAN H and CAN L) will start the CAN bus
  • This board needs to be terminated to the 120 Ω by setting respective jumpers on it
• One or multiple further CAN boards, e.g. tool-boards, are connected to this “master printer board”
  • The boards “in the middle” of the CAN bus must not be terminated
  • The last board at the end of the CAN bus must be terminated to the 120 Ω by setting respective jumpers on it
• Not shown: The printer board and all the CAN boards need a connection to the main power supply unit of the printer

3. Configuring Klipper for the different Architectures

Depending on the chosen architecture, the initial setup and also updating Klipper works a bit differently.
Since this article shall only offer a brief introduction to the CAN concept, the details on the individual approaches are outlined in the article <Work in Progress>

############################

Comments of course welcome

[willpuckett]

Looks great!

[koconnor]

Thanks. Looks good to me.

Some minor notes:

@Sineos

Does not use precious USB ports on the commonly used Single Board Computers (SBC)

FWIW, I personally don’t think that is an advantage of CANbus. In my opinion the advantage of CANbus is the simplified and extensible wiring. In particular, being able to deploy appropriate wiring to toolheads/carriages that are frequently moving, and/or that require wire routing through cable chains or other constrained spaces. If the mcu isn’t moving and the wires aren’t constrained then I think USB is a superior choice - I’d buy a USB hub if I was low on USB ports.

@Sineos

Not suited if used within heated chambers, at least if the temperature rises above around 80°C - 100°C

This isn’t a limit of CANbus. Indeed, CANbus is regularly used in automotive environments with high heat. Temperature is a limit of some toolhead boards regardless of protocol. (Though it is, at least theoretically, possible to obtain a toolhead board rated for high temperatures).

@Sineos

All Nodes internally consist of 3 different function blocks:

There are three components, but I’d describe them a little differently - there is the transceiver chip, there is the CAN hardware block, and there is the CAN aware software. The transceiver chip is a separate silicon chip found on a CAN capable board. The CAN hardware block is part of the micro-controller silicon (typically found on stm32, atsame, and similar chips). The CAN aware software is Klipper.

The rp2040 is a slightly different case - on that chip the “CAN hardware block” is implemented in software using the can2040 software. There are still 3 parts - transceiver, can2040, Klipper. The can2040 software is automatically installed when building Klipper on rp2040 with CANbus, but it is still a distinct piece of software (see lib/can2040 in the Klipper repo).

Cheers,
-Kevin

[koconnor]

@Sineos

Each participant to the bus is called a Node and is unequivocally identified on the bus via a Universally Unique Identifier (UUID).

Also, as a minor point, the UUID stuff is purely a Klipper convention. It isn’t true of the CANbus protocol itself. (The rest of that paragraph notes things that are true about the CANbus protocol in general.)

@Sineos

To prevent reflections and ringing on the bus, the start and end of the bus are terminated with 120 Ω resistors.

Super minor - the resistors reduce reflections/ringing and are also used to return the bus to a “recessive” state from a “dominant” state after each transmitted bit of information. FWIW, it’s this second part that makes the resistors required for typical 3d printers (with the short cable lengths we typically use, the reflections are often not a problem in practice).

Cheers,
-Kevin

[Sineos]

Thanks a lot for the input. For my own understanding super valuable, but I want to target the article to the every-day user as a “general understanding”.
I’ll see where I can get a bit more precise without “drifting into TL;DR”.

[Sineos]

Updated the article:

• Reflect @koconnor’s feedback
• Some work on the illustrations
• Some minor wording corrections