Serial Data Rate Adjustment

General Discussion
1

I am looking into making a Voron 2.4 with CAN tool changers and CAN stepper motor drivers in order to simplify wiring. With that said, I have concerns of saturating CAN communication.

I asked a Klipper Dev about CAN limitations within Klipper and was informed all serial communication to Klipper is set to 250Kbits/s for all types of serial communication (example: USB, CAN, UART, SPI, I2C).

Therefore my question is as follows:

  • If I have a BTT SKR3 EZ main control board

  • and four EBB36 tool boards

  • and a FSYTEC PITB CAN board to control A and B stepper motors

  • all connected to a BTT CEB CAN hub,

  • this would result with one main control board to communicate with five MCU’s using one CAN network.

Does Klipper allow changing CAN communication to a higher baud rate if needed?

If so, does Klipper have a maximum data rate for adjusting serial communication?

2

@Sineos I assume you would know answers to these question. Could you help?

3

Up to 1Mbits/s, just use the search function here.

4

Not sure if I can meaningful support.
Klipper supports a data rate of up to 1 Mbit. If this is sufficient for your use case, I cannot tell.

Generally speaking, you could also connect the tool-boards directly to the host via USB and potentially a USB hub. If the tool-boards are not moving, then CAN does not offer any real world advantages.

5

Thank you for your reply.

Does this mean that Klipper does not support the higher speeds of CAN-FD 5Mbit/s?

Also, are other serial communication speeds adjustable, like USB, SPI, UART…?

If so, how are these other serial communication speeds adjusted if the default speed is 250Kbits/s?

For example, if I use four USB Orbiter toolboards with a USB hub rather than four CAN EBB36 toolboards, will USB communication stay limited to 250Kbit/s?

6

You may have a look on this thread:

1 Like
7

Thank you for your reply.

Are other serial communication speeds adjustable, like USB, SPI, UART…?

If so, how are these other serial communication speeds adjusted if the default speed is 250Kbits/s?

For example, if I use four USB Orbiter toolboards with a USB hub rather than four CAN EBB36 toolboards, will USB communication stay limited to 250Kbit/s?

8

No

Not that I’m aware.

Not an expert here, but I do not think that bandwidth is your overall issue, especially on separate USB connections.
In the end, one printer board could easily support all kinematic steppers and for your tool changer, only one tool will be active at any given time.

9

Thank you for your reply.

I was informed that Klipper sets all serial communication speeds to 250Kbit/s as default which includes USB.

For example, if I use four USB Orbiter toolboards with a USB hub rather than four CAN EBB36 toolboards, will USB communication stay limited to 250Kbit/s?

What is the maximum USB speed that Klipper supports?

10

This question would need to be addressed by a developer.

Out of curiosity, why are you so focused on the bandwidth topic? Klipper can sustain extremely high step rates, which are not limited by bandwidth since Klipper sends compressed binary data. Instead, the limitation lies in the processing capabilities of the MCU. For more information, see the relevant benchmark chapter in the documentation: Benchmarks - Klipper documentation

11

Thank you for your reply.

I have a background in testing automotive CAN. From this experience, I know it is important to verify or at least approximate the remaining bandwidth of a CAN network before adding additional CAN modules.

Since a Klipper user can add many MCU’s to a single CAN network, like in the example I provided in the first post, I assumed the Klipper team had an estimation tool or test to determine remaining bandwidth of a serial communication like USB or CAN.

From my interaction with a Klipper Dev, I was informed the Klipper Team does not have an estimation tool or test to determine remaining bandwidth of CAN, which I found a bit alarming.

Think about this for a bit… A Klipper user can design a CAN network for their printer but they have to do so completely blind to network bandwidth. That is not good design practice and sounds like a problem waiting to happen. Therefore, I am looking to understand bandwidth limitations within Klipper for CAN and USB to prevent purchasing equipment, like in the example I provided in the first post, that will not work due to bandwidth limitations.

Thank you for providing the link to the MCU benchmark information. Unfortunately, this information does not help understanding the limit of how many MCU’s can be added to CAN or a USB hub before the network becomes a bottleneck.

Does that help with understanding why I am focused on bandwidth?

I appreciate your help.

12

To start off with, I know where you are coming from wanting to be able to characterize the CAN hardware and software used in 3D printers. I have a background in design and manufacturing with experience in very high reliability systems as well as automotive, aerospace as well as wireless communications. If you do a search on this Discourse page, you can see that I have challenged a number of ways things have been done and helped people with various electrical/electronic implementation issues (many of which involve CAN).

One of the hardest things for me to accept is that 3D printing is a hobby.

This is reflected in the products available for 3D printing as well as the approaches people take to doing things. There are many things I see in the electronics used in 3D printers that makes me shudder as well as frustrates me to no end although I’ve been told several times to stop bitching because it works.

Don’t forget that 3D printing really started with Arduino and many of the interfaces, circuitry and hardware used in 3D printing were designed by hobbyists who “knew” something about electronics but did not work to any kind of standards or have an understanding how to test what they were creating. This legacy really is a detriment to having stable systems that are easy to support and replicate problems on to fix them.

CAN is an example of this ideal, attitude and the approaches used in 3D printing. While the Klipper software is excellent, the same can’t be said for the hardware that runs it. There are a variety of different devices from different manufacturers (including devices and MCUs that are no specified in the schematics), running at different clock speeds. Many of these devices run (CAN) software that is outside of the Klipper project and there are various versions in play depending on the device and the user. Don’t forget that each manufacturer’s board has its own transceiver, choke and connector scheme and people are very casual with making up CAN cables.

To net things out, it’s not possible to characterize CAN performance in general and probably extremely difficult to characterize it for a specific set of hardware. If you insist on doing this work, I suggest you use a TDR to make sure your CAN bus lines have no major impedance discontinuities in them and will not be an impediment to the CAN bus’ performance.

Again, I get where you’re coming from but I think you need to take a step back and accept that this is a hobby and that’s the way it’s been approached.

When I saw your post originally, I felt like you are being somewhat aggressive for setting up a CAN network for 3D printers.

My recommendations to you are:

  1. Use a Manta M8P for your main controller board. This has a built in CAN interface that works very well and means less wiring and setup than having a separate U2C board. Also the two extra stepper drivers means that you can avoid using the FYSNCH PITB board. You could also use an Octopus if you want a faster MCU.
  2. If you insist on using the BTT SKR3 EZ board, don’t use the EZ stepper adapters. They’re oversold and not that reliable. Use the standard 18 pin stepper driver modules.
  3. Avoid using the BTT CEB CAN Hub. Keep your CAN bus to a single, linear line with as short stubs as possible.

As a practical note, rethink your use of the FYSNCH PITB board - it uses the rPi 2040 which is an okay MCU but it’s different from the STM32s on all the other boards you’re planning on using. Actually, the reason why I suggested that you use the Manta M8P is that it uses the STM32G0B1, the same as the EBB36 tool boards - that way you have a more consistent firmware load process.

Good luck and let us know how you make out.

13

Myke,

Thank you for your thorough reply and suggestions.

Thank you for your helpful reply.

14

I have been communicating with Klipper Devs to get CAN and USB information that I am seeking. Since I have answers to these difficult questions, I am going to compile this information here for CAN and USB.

EDIT: Please see koconnor’s very concise post below which I marked as the solution.

CAN

Baud rate for CAN MCU’s (toolboards and other CAN devices) is set when configuring the

make menuconfig

command for making Klipper firmware. The MCU portion of the printer.cfg file must also match the baud rate that was defined when making the firmware. If the default baud rate is used during the firmware make process, which is 250Kbits/s, then the printer.cfg file does not need to define the baud rate for that MCU, since 250Kbits/s will be assumed if not defined by default.

Interesting fact, all MCU’s have the same default baud rate of 250Kbits/s no matter which serial communication type is used (CAN, USB, UART, SPI, I2C…).

The maximum baud rate for CAN is 1Mbits/s which supports CAN 2.0. Interesting note: CAN-FD and CAN-XL will not be implemented into Klipper due to much work is needed to implement faster versions of CAN but there is little gain in speed for this work.

With that said, one developer has confirmed his EBB CAN toolboard uses about 20Kbits/s of bandwidth, therefore faster versions of CAN should not be needed no matter how many MCU’s are using the same CAN-Bus.

* It is recommended to first read this information before setting up CAN on your printer.

* If you are experiencing problems with CAN, then it is recommended to read this troubleshooting information.

USB

USB functions just as any other USB device from the device to the Raspberry Pi (USB 2.0 or USB 3.0 speeds available depending on how the Pi is equipped). BUT, from the Raspberry Pi to Klipper, the MCU baud rate is set to 250Kbits/s as a default of Klipper. If you want to increase the baud rate of a USB MCU, then you only need to change the baud rate in the printer. cfg file.

If you have a use case that uses five tool changers which use USB toolboards (Orbiter), then you will need to use any high quality USB hub. This USB hub should work very well with a Raspberry Pi 3 or 4. If you add too many devices to the USB hub (like a camera and five Orbiter toolboards), then you will likely want to use a Raspberry Pi 4 since the Raspberry Pi has two USB chips that separate USB load between USB 2.0 and USB 3.0. Note: Raspberry Pi 3 only has one USB chip to support the four USB 2.0 ports on the Pi.

Key differences between CAN and USB with regard to baud rate

* You should never need to increase the baud rate of a USB toolboard. USB is more than fast enough communicate between the USB toolboard thru the USB hub then to the Raspberry Pi and back. Adjusting the baud rate of a USB device only changes the speed between the Pi and Klipper. If the baud rate needs to be increased, then the config settings from the toolboard manufacturer should state the recommended baud rate.

* All CAN MCU’s on a single CAN-Bus must be configured to the same baud rate. This baud rate configuration is performed when making the Klipper firmware for that MCU as well as the MCU definition within the printer.cfg file should also match the baud rate of the firmware.

* In most cases, the default baud rate for CAN (250Kbits/s) should be sufficient for multiple toolboard MCU’s on a single CAN-Bus. If the default baud rate is not sufficient, Klipper will alert you with plenty of errors. Changing the baud rate of a CAN network is undesirable since each MCU on the CAN-Bus will need the firmware remade and reinstalled. Therefore, most people will setup their CAN MCU’s at the maximum baud rate of 1Mbits/s if they will have multiple MCU’s on a single CAN-Bus.

2 Likes
15

Some notes:

  • Klipper defaults to a CAN bus frequency of 1Mbit/s. Using 1Mbit/s is also the recommended frequency: CANBUS - Klipper documentation
  • Klipper only defaults to 250Kbit/s for UART (aka serial) connections.
  • When Klipper is compiled for USB the transfer rate is determined by the hardware and Linux scheduling. Setting “baud” when using micro-controller hardware USB has no effect.

If you are looking to measure the actual CAN bus usage, then I’d recommend looking at the Linux CAN bus tools. Klipper uses the Linux kernel to send/receive CAN packets, which has several tools for recording and monitoring traffic on the canbus. For example, see the description of how to install the can-utils package at: CANBUS Troubleshooting - Klipper documentation

-Kevin

16

Thank you for taking time to reply to this thread. I spent much time trying to compile this information and as SineOS recommended, I inquired with a Klipper dev. Attempting to get accurate and consistent input has been difficult. Therefore, I am grateful for your input.

With regard to USB data rate, I was informed the data rate limitation was between the RPi hardware and Klipper, with the data rate limit set in the MCU config as shown here. Does the MCU config setting limit USB data rate within Klipper?

I was also told that ALL serial communication data rate has a default rate of 250Kbit/s, which appears to align with this information here and here. Is the information in these links incorrect or only specific to UART? If only specific to UART, is there similar information available for other serial communication protocols?

Thank you again for your help.

17

No. If one compiles the micro-controller to use USB then there are no rate-limits on that connection. The available bandwidth is determined by the USB hardware (typically 12Mbit/s full-speed USB) and Linux’s USB scheduling.

I’m not sure what you are asking. As before, if the micro-controller is compiled for serial (aka UART) then the default is 250Kbit/s.

This is all related to the selections in “make menuconfig”. There is typically an option for “Communication Interface” in that menu. If one selects “CAN” then the default CANbus frequency is 1Mbit/s; if one selects “Serial” the the default is 250000 baud; if one selects “USB” then the bandwidth is determined by the usb hardware and there is no ability to impose an arbitrary rate-limit.

-Kevin

18

Would it be correct to state that the effective USB data-rate is then negotiated depending on the hardware connected to the port, e.g. full-speed for native STM32 USB or depending on the respective USB-to-Serial Bridge chip?

19

I’m not sure I understand the question. The particular USB interface speed (ie, low-speed, full-speed, high-speed, or superspeed) is generally dependent on the usb device, usb host, and usb hub hardware - most micro-controller hardware implements “full-speed”.

-Kevin

21

In the case of a USB to Serial adapter bandwidth would still be limited by the hardware UART on the MCU, so 250000 by default.

I think its necessary to be careful when attempting to document the difference between a real UART and an emulated serial connection. If the user configures the baud rate as if its always using a real UART then everything should work. Trying to differentiate between the two may just be confusing for some users.