Klipper Feature Request: Detachable MCU for Detachable Accessories

Features
1

Introduction

This feature request proposes the implementation of support for detachable MCUs. It’s specifically designed for managing detachable 3D printer accessories like ADXL345 sensor module and Multi-Material Units that are not permanently affixed to the printer.

Problem Statement

Currently, accessories with their own MCU like an ADXL345 modulean MMU requires static Klipper configuration. When these accessories are designed to be easily detachable, the need for manual configuration changes becomes cumbersome.

  • ADXL Sensor: After calibration, the sensor is often removed. This involves manually commenting out sections of the Klipper configuration. If the sensor’s MCU is simply unplugged without configuration changes, Klipper reports an error, preventing further use until the configuration is adjusted or the MCU is reconnected.
  • MMU: Multi-Material Units are complex accessories with complex configuration files. Currently, switching between single and multi-material configurations in Klipper requires the use of bypass function to temporarily disable MMU functionality, attempting to run Klipper with the MMU disconnected results in immediate errors.

Proposed Solution: Detachable MCU Module

Klipper would need to be enhanced to:

  1. Auto-detection/Hot-plugging: Automatically detect the presence and identity of the detachable MCU when it’s connected.
  2. Dynamic Configuration Loading & Switching: Implement the ability to dynamically load, enable, or switch between different sets of Klipper configuration files or profiles based on the detected accessory MCU.
  3. Graceful Disconnection: Handle the disconnection of the non-critical accessory MCU without requiring a full Klipper restart or causing errors. This is paramount to addressing the current MCU error issue. This might involve:
  • Switching to a default profile (e.g., single-material printing when MMU is detached).
  • Marking the disconnected MCU as “optional” or “offline” rather than “not found” to prevent hard errors.
  1. API for Accessory Control: Provide an API for the main Klipper instance to interact with complementary softwares.
2

  1. Klipper does not have an official plugin system. Discussions about this are ongoing, but nothing tangible yet. Without such a system, the hotplugging of MCUs and associated configurations seems like targeting unknown modifications and their behavior, finally putting the burden of failure and maintenance on Klipper.

  2. As far as my understanding goes, the host and the MCUs perform an intricate handshake at startup to also validate the same protocol and feature sets, etc. While surely not impossible, switching this into a hotplugging architecture sounds like complex work.

  3. For simpler MCUs like the quoted ADXL, an easy workaround exists: Put its configuration into an included cfg. (Un)commenting this is only minimal work and usually not done regularly.

My personal view:

  • Yes, it is an interesting feature, but with a low priority
  • Working on fundamental improvements like overhauling the homing system or providing a general plugin interface seems a lot more rewarding with a much higher user impact.
  • Unfortunately, the developers here refuse to dedicate 120% of their time (including the night) to Klipper despite having been called to do so numerous times.
3

You might want to look at how Kalico does this with its optional MCU feature.

As for dynamically loading configs, it should be possible to write an extras module to read the connected serial devices on startup, and inject the relevant config. This method requires a restart, but is much more stable. Alternatively, you could combine this with the optional MCU feature in Kalico.

Either way, this isn’t natively supported in vanilla Klipper, but nobody’s stopping you from modifying it to your needs. Just keep in mind that you will have a hard time getting support if you do some deep changes.

4

I mean. Just give ability for klipper to restart to a different printer_config folder and expose it as an api. I think devs from other projects will handle the rest.

How could this be lower priority than overhauling the homing system? Something that’s already rock solid and no need to be fix.

5

Currently I am just using simple shell script that replaces all files in the printer_config folder with all files from another folder then restart.

I could do a swap from mainsail and klipperscreen with this method, but values in SAVE_CONFIG and github backup are messed up.

6

That seems unnecessary. When testing I use symbolic links to switch between configurations. The config I need is linked to printer.cfg, then all that is needed is a restart of Klippy.

Edit: Scratch that, it is how I used to do it but it doesn’t play nice with SAVE_CONFIG. Now I use a systemd environment file and change the name of the config file when I want to swap. Alternatively I create a symbolic link to klippy.env from an environment file that contains the full arguments I need to launch Klippy.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.