Optimizing 3D Printing with Hard Real-time Linux on Raspberry Pi

1. Introduction

3D printing and Raspberry Pi devices have gained widespread popularity as essential tools for hobbyists, students, and professionals engaged in prototyping. In recent years, 3D printers have started to integrate Internet of Things (IoT) capabilities into their daily operations. By connecting a Raspberry Pi to the 3D printer's mainboard, it becomes possible to remotely power on the printer and manage print jobs over the internet, eliminating the need for in-person supervision. But what if you configure the Raspberry Pi to serve as the 3D printer's mainboard, with the added advantage of running a full-fledged operating system?

Single-board computers (SBCs) such as the Raspberry Pi and Beaglebone have made significant progress in achieving excellent compatibility with existing Linux software and kernel modules, thanks to the development of robust hard real-time solutions. When SBCs run Linux with hard real-time capabilities, they can seamlessly support projects like Klipper and Fluidd, as well as various hardware components including stepper drivers, temperature sensors, and accelerometers. This eliminates the necessity to rewrite software and drivers for specific real-time operating systems (RTOS). With the abundance of Linux software and compatible devices, there are numerous solutions and applications available to transform a Raspberry Pi into a capable 3D printer.

This report outlines the initial exploration into configuring a Raspberry Pi running Linux with hard real-time extensions to control stepper motors and execute the kinematics of a 3D printer, leveraging Adafruit DC & Stepper Motor Pi HATs.

Figure 1: Raspberry Pi with Stepper Motor HATs 3D printer Setup. The Raspberry Pi is in the bottom right,

2. Background

3D Printing

3D printing is an application that operates under strict time constraints, involving the transformation of virtual 3D models into physical objects. The process for 3D printing is a series of essential steps: it begins by interpreting a list of instructions for constructing the 3D model, then executes these instructions line by line. It meticulously manages the movements and functions of its mechanical components in accordance with each instruction until all instructions have been processed [1]. Ultimately, this process results in the creation of a tangible object in the physical world.

The successful execution of 3D printing hinges on the printer's ability to consistently and promptly carry out these commands. If the printer fails to complete an instruction within its allocated timeframe, the entire operation may be compromised. In summary, the world of 3D printing demands adherence to stringent hard real-time constraints to ensure that its timing requirements are met.

Figure 2: Creality Ender 3 3D Printer.
  • Hard Real-Time for Linux

Research into the realm of hard real-time capabilities within the Linux operating system has garnered significant attention, particularly as Linux has gained widespread popularity among both developers and users. The essence of real-time computing lies not solely in completing tasks at maximum speed but also in initiating tasks with utmost promptness. This concept underscores the critical requirement for real-time applications to swiftly respond to specific events within predefined time limits, often referred to as deadlines. In the realm of hard real-time, the adherence to these deadlines is of paramount importance, as any failure to do so can lead to system malfunction or breakdown.

This demand for hard real-time capabilities becomes particularly pronounced when various devices must coordinate processes within tightly constrained time intervals. For instance, if a computer intends to launch a rocket into the air within precisely 10 seconds, it relies on the rocket's ignition happening at the exact 10-second mark. Any disruptions or delays in the computer's operations could result in catastrophic failure for the rocket. To avert such dire consequences, the computer must consistently execute processes in strict accordance with the specified deadlines.

Over the past two decades, projects like PREEMPT_RT and Xenomai have diligently strived to embed robust hard-real time capabilities into the Linux kernel. Nevertheless, the integration of these projects into the Linux mainline development was a relatively recent development. In August 2021, a substantial portion of the PREEMPT_RT project found its way into the mainline Linux development branch. This momentous integration signifies a significant stride toward enhancing hard real-time capabilities on the Linux platform, rendering it more accessible and applicable for a wide range of applications that can derive substantial benefits from this inclusion, such as Klipper.

  • PREEMPT-RT Patch

The PREEMPT-RT patch enhances the Linux kernel with hard real-time capabilities, achieved by enabling preemptibility throughout the kernel. In simpler terms, this patch empowers real-time tasks to take precedence over the kernel's operations. As a consequence, system process throughput is sacrificed for reduced latency [3]. Unlike alternative methods for incorporating hard real-time features into Linux, this patch maintains the integrity of Linux as a single unified kernel. This unique characteristic enables developers to create real-time applications without the need for substantial adjustments. Consequently, this capability allows us to control stepper motors efficiently without the necessity of introducing additional real-time utilities in Klipper.

  • CPU Isolation and Affinity

One challenge encountered by real-time applications is the contention for processor resources from other concurrent processes. CPU isolation and affinity mechanisms offer solutions to guarantee that specific applications are not disrupted or delayed by competing processes [5]. CPU isolation entails the separation of a processor or thread from the standard scheduling routines [6]. Isolated processors can be designated exclusively for real-time applications, allowing them to execute without interference from other processes. However, to achieve this, programs must incorporate CPU affinity functions to establish a connection between the application and the isolated processor. Figure 3 illustrates the impact of CPU isolation.

Figure 3: Effect of CPU Isolation. Processor 3 no longer acquires tasks from the default scheduler.

CPU affinity involves the capability of associating processes with specific processors [7]. Instead of relying on the Linux scheduler to automatically allocate new processes to any available processor, developers have the option to determine the processors on which these processes should execute. In Linux, two interfaces for managing CPU affinity are sched_setaffinity and cpuset. The sched_setaffinity function, found in sched.h, enables the explicit specification of processors or threads to which a process can be assigned [7]. Another method for handling CPU affinity is through the use of cpusets, which offers a means to allocate a defined set of CPUs and memory nodes to a collection of tasks [8]. Similar to sched_setaffinity, cpusets enable the allocation of tasks to a designated group of processors. Of particular note is the ability of these CPU affinity interfaces to assign tasks to isolated processors or specific sets of processors. The experiments detailed in section 6 provide evidence of the effectiveness of these CPU isolation and affinity interfaces. Figure 4 illustrates the process of CPU affinity, as it allocates a real-time task to an isolated processor.

Figure 4: CPU Affinity on the Isolated Processor 3.
  • Klipper

Klipper represents a 3D printer firmware that integrates single board computer processors and 3D printer mainboards into a unified system, providing 3D printers with enhanced computational capabilities [9]. In the past, other 3D printer firmware would task a single microcontroller with both file processing and managing the printer's components. Klipper, on the other hand, orchestrates the collaboration of multiple computers and printer mainboards to function as a cohesive 3D printer unit. As 3D printer firmware continues to evolve and add more features, microcontrollers struggle to keep up with the increasing processing demands. Klipper addresses this issue by implementing a strategy that effectively shares processing power across various processors and microprocessors.

The primary appeal of Klipper lies in its efficient workload distribution among processors and microprocessors. Klipper delegates the tasks of reading files, processing data, and computations to a computer, thus relieving the 3D printer's microcontroller of these responsibilities. This, in turn, frees up the microcontroller's processing resources for managing the printer's components. In theory, this results in reduced contention and lower risk of overutilization of the microcontroller. Furthermore, the computer and microcontroller can collaborate and share GPIO pins, expanding the functionality available to the 3D printer.

Figure 5: Klipper Ecosystem.
  • Structure

Klipper's architecture consists of two key components: the Klipper MCU and Klippy. Each of these components plays distinct roles in the creation of the firmware and the operation of the 3D printer.

The Klipper MCU (Microcontroller Unit) is responsible for managing low-level hardware interfaces within the Klipper system. It offers support for various hardware interfaces and protocols, including general-purpose input-output (GPIO) and serial peripheral interface (SPI), tailored to the specific architecture of the processor. Additionally, the MCU stores all the commands required for operating the supported interfaces. These commands serve as the basis for the MCU's scheduler, which queues tasks for hardware control. Typically, end-users do not directly interact with the MCU, unless there is a need to integrate a specific protocol or hardware. In essence, the MCU prepares the necessary instructions and utilities for Klippy's use.

Klippy serves as the high-level interface responsible for the general operation of the 3D printer. When the printer is initialized, users specify the devices used in their 3D printers through a configuration file. Subsequently, Klippy retrieves the essential software modules listed in the configuration file needed to operate the 3D printer. Once created, Klippy takes charge of printer operation whenever the user sends a command or print job. Following a restart or shutdown, Klippy revisits the configuration file and repeats the same processes. Furthermore, external applications such as Octoprint, Mainsail, and Fluidd interact with Klippy to provide users with a front-end web application for managing their printers.

Figure 6: Klippy and Klipper MCU.
  • Scheduling

The scheduler employed by Klipper plays a pivotal role in the seamless operation of the 3D printer. The primary scheduler responsible for controlling the printer's hardware is housed within the printer's processor. Both the MCU and Klippy engage in communication to effectively manage the scheduling of tasks for accessing the printer's devices. Typically, it's Klippy that initiates task requests for the MCU to carry out. This scheduling sequence is depicted in Figure 7 and unfolds as follows: 1. Klippy receives a high-level command, 2. Klippy interprets the command, translating it into a low-level command suitable for the MCU, 3. Klippy dispatches the command to the MCU, 4. The MCU receives and processes the command, 5. The MCU adds the command to its scheduler, 6. Finally, the MCU executes the command when it reaches the front of the queue.

Ensuring the smooth operation of the 3D printer hinges on the effective maintenance of this scheduler.

Figure 7: Klipper’s Scheduler.

3. Related Works

  • Real-time Operating Systems

Numerous real-time operating systems (RTOS) have emerged with the primary objective of equipping systems with real-time capabilities. Specifically, these operating systems are designed to ensure that tasks and computations meet predetermined constraints and deadlines, particularly in applications where timing is critical, as detailed in reference [3]. Applications such as robotics and motion control in 3D printing demand the ability to promptly regulate motors when required. To fulfill this necessity, the chosen operating system must possess the capacity to process and disseminate instructions within specified deadlines. Each RTOS comes with its own set of drawbacks and limitations, making the selection process challenging. Notably, the Zephyr Project and Xenomai represent two alternative RTOS options alongside the PREEMPT_RT patch, offering viable solutions for enhancing real-time capabilities on the Raspberry Pi for 3D printing.

  • Zephyr

The Zephyr Project stands out as an extensively adaptable Real-Time Operating System (RTOS) designed to cater to a diverse range of resource-limited devices and architectures [10]. This initiative empowers users to meticulously tailor a wide array of features, encompassing kernel extensions, firmware, and support for specific architectural requirements, all aligned with their particular application needs. This approach ensures that the OS maintains a small memory footprint, enabling applications to maximize their utility within constrained resource environments. It's noteworthy that, as of the time of this writing, the Raspberry Pi is not officially integrated into the project's supported devices, necessitating additional efforts for the incorporation of the Zephyr OS onto this platform.

  • Xenomai

Xenomai serves as a dedicated hard real-time framework specifically designed to manage time-critical operations, operating in conjunction with the Linux operating system. Essentially, Xenomai is a component entirely focused on hard real-time tasks. Unlike PREEMPT-RT, Xenomai offers users the flexibility to employ it as a co-kernel alongside Linux in a dual kernel configuration, or it can be integrated as a targeted API within the Linux kernel itself to manage interrupts and schedule real-time threads [11]. This approach has demonstrated its ability to achieve reduced latency in numerous tests, outperforming PREEMPT-RT in this regard [3]. However, it's worth noting that Xenomai necessitates a more intricate process for integrating its own non-POSIX API and system calls into applications, which can pose challenges when porting older real-time projects. Additionally, it's important to highlight that Xenomai may not offer the same level of hardware support as the Zephyr Project.

  • 3D Printer Firmwares

Over the past decade, open-source 3D printer firmwares have enjoyed substantial popularity. In most cases, these firmwares offer the necessary infrastructure for the hardware components to function and shape a 3D printer. However, the designs of these firmwares significantly impact the simplicity of integrating new devices. Notably, when it comes to incorporating the HATs utilized in this project, RepRap Firmware and Marlin might have posed greater challenges than Klipper due to their lack of native support for the Raspberry Pi's processor architecture.

  • RepRap Firmware

RepRap Firmware (RRF) is a firmware designed specifically for 3D printing on 32-bit microcontrollers [12]. This firmware places a significant emphasis on the utilization of G-Codes as the primary means for configuring and controlling the 3D printer. In its most recent iterations, RRF has integrated FreeRTOS, a real-time operating system for microcontrollers. Nevertheless, it's important to note that RRF offers support for fewer microcontroller architectures when compared to Marlin and Klipper. Notably, RRF does not include support for the processors commonly used in Raspberry Pi devices.

Figure 8: RepRap Firmware on a Duet WiFi Mainboard [12]. The diagram shows how the firmware interacts with the components on the Duet WiFi.
  • Marlin

Marlin stands out as a 3D printer firmware compatible with a wide range of microcontroller architectures, spanning both 8-bit and 32-bit systems [13]. These supported microcontrollers are commonly featured in Arduino/Genuino platforms. Marlin is a prevalent choice among consumer 3D printers, including popular models such as those from Prusa and Creality3D.

While Marlin's extensive support for diverse hardware is an appealing factor, it should be noted that it lacks native compatibility with the Raspberry Pi. Consequently, Marlin was not considered as a viable option for the project.

Figure 9: What is Marlin? [13]. The diagram depicts how Marlin is responsible for operating the controller board that drives the 3D printer.
  • 3D Printer Expansion Boards

Historically, there have been various attempts to create expansion board solutions aimed at facilitating 3D printer interfaces for devices like the Raspberry Pi and similar single-board computers (SBCs). These solutions often involved the incorporation of supplementary microcontrollers to compensate for the inherent absence of hard real-time capabilities in the SBCs' processors. Although the present solution within this project doesn't encompass interfaces for thermal control with the Raspberry Pi, this section scrutinizes the communication and operational methods of each of these boards when it comes to managing stepper motor drivers.

  • Aperio

Aperio, a proposed Raspberry Pi HAT (Hardware Attached on Top) featured on Kickstarter, was designed to integrate hardware components managed by a microcontroller. This combination aimed to enhance the Raspberry Pi's capabilities for applications such as robotics, home automation, 3D printing, and other Internet of Things projects [14]. In this context, the Raspberry Pi would be required to establish communication with Aperio's microcontroller to oversee the stepper motors. The Raspberry Pi alone lacks full control over these stepper motors. In contrast, this Master's project demonstrates that the Raspberry Pi can operate the stepper motors for the 3D printer without the need to communicate with an additional microcontroller. It achieves this by directly interfacing with the stepper motor drivers integrated into the Stepper Motor Pi HATs.

Figure 10: Aperio Raspberry Pi HAT.
  • Replicape

The Replicape serves as a 3D printer controller board designed to be connected to the BeagleBone Black [15]. The BeagleBone Black is a Single Board Computer (SBC) that is equipped with a primary processor and programmable real-time units (PRUs). These PRUs are additional processors that can be allocated to manage real-time processes [16]. Within the Klipper framework, the PRU can function as the Klipper MCU for controlling the 3D printer's components, while the primary processor can handle front-end applications for operating Klippy. By designating the PRU to oversee tasks such as managing stepper motors and temperature sensors, the Replicape can effectively meet the stringent hard real-time requirements for the Klipper MCU in 3D printer operation.

The methodology outlined in this paper strives to demonstrate that SBC processors can satisfactorily control stepper motors without necessitating the use of PRUs.

Figure 11: Replicape for the BeagleBone Black.
  • PandaPi 3D Printer Controller

The PandaPi functions as a controller board for 3D printers, designed for attachment to the Raspberry Pi [17]. Control of various components is divided between the Raspberry Pi's processor and the PandaPi's STM32F103RCT6 MCU. The MCU is responsible for managing the heaters, thermistors, and fans, while the Raspberry Pi processor oversees the operation of stepper motors through its GPIO pins via UART communication. In a distinct manner from other expansion boards, the PandaPi operates with a customized version of the Marlin firmware, which harmonizes the efforts of the Raspberry Pi processor and the MCU to function in tandem. This configuration closely resembles the multi-MCU model adopted by Klipper.

Figure 12: PandaPi 3D Printer Controller V2.9 [17]. Left: the PandaPi with a Raspberry Pi 4 attached on top. Right: complete view of the PandaPi.

4. Architecture

The outlined system architecture enables the Raspberry Pi to function as a 3D printer controller. Within the Raspberry Pi, software is configured to facilitate the acquisition of Linux hard real-time extensions by the processor, along with the utilization of CPU isolation and affinity for the Klipper MCU.

The kernel is configured to enable preemptibility and provides essential firmware for the hardware. In the Raspberry Pi OS, cpusets are employed to partition the allocation of processors for various system tasks.

By default, most processes are assigned to the parent cpuset, which then delegates tasks to any available processor. User applications like Klippy and SSH are managed by the scheduler. It's worth noting that Klippy serves as the primary means of communication with the Klipper MCU, handling tasks such as assigning print jobs and executing commands.

Within the parent cpuset, a dedicated child cpuset is established for the isolated processor responsible for hosting the Klipper MCU. The Klipper MCU's role is to establish and control the hardware components of the 3D printer, including stepper motor drivers and temperature sensors, interfaced through the Raspberry Pi's GPIO headers. This isolation is a crucial element in ensuring that the Klipper MCU operates within the stringent constraints of hard real-time processing.

Figure 13: Architecture of a Raspberry Pi that runs real-time Linux for 3D Printing.
  • Hardware

The key components for this project consist of the Raspberry Pi 3 Model B+ (RPi) and Adafruit DC & Stepper Motor HATs (Motor HATs). You can see each of these hardware elements in Figure 14. The Motor HATs will be affixed to the GPIO pin headers of the RPi. This arrangement enables the RPi to establish communication with the Motor HATs via I2C, which is essential for managing the stepper motors. To be more precise, the PCA9685 PWM driver chip will be responsible for controlling the TB6612 motor drivers, which, in turn, govern the stepper motors' operation. You can observe the communication process between the RPi and the stepper motors in Figure 15. In the current setup, this configuration provides the necessary physical capability to handle the kinematics of the 3D printer. Notably, because the Motor HATs utilize only two GPIO pins for I2C communication (specifically GPIO 2 and 3), the remaining GPIO pins can be allocated for additional accessories used with the 3D printer. The complete assembly of the Raspberry Pi and the stepper motor HATs is illustrated in Figure 16.

Source: Optimizing 3D Printing with Hard Real-time Linux on Raspberry Pi


About The Author

Ibrar Ayyub

I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.

Follow Us:
LinkedinTwitter
Scroll to Top