Cover generated in ChatGPT

My Voron 2.4 sat idle for months.

When a printer like this goes unused for a long time, getting back to printing is not simply a matter of switching it on and sending a file. Before that comes the ritual many people know: updating Klipper, Moonraker, Mainsail, plugins, firmware, dependencies, and trying to remember everything that was installed, tested, and changed in the past.

It was during this process that the problem appeared.

After the updates, Klipper stopped starting with the error:

Internal error during connect: __init__() missing 1 required positional argument: 'param_helper'

From that point on, I used AI as a technical copilot, connected via SSH to the printer's Raspberry Pi, to diagnose, fix, clean up, and reorganize the entire environment.

The printer is a Voron 2.4 with Klipper, Moonraker, Mainsail, an Octopus in USB-CAN bridge mode, an EBB over CAN, and StealthChanger/KTC-Easy.

The environment before the cleanup

The Klipper error was just the symptom.

The environment carried its history. During assembly, tests, and attempts at improvement, various things had been installed: a camera, timelapse, speed plugins, experimental modules, old configurations, and references that were no longer part of the printer's current use.

The most important case was the toolchanger.

My printer uses StealthChanger/KTC-Easy, but there was still a lot of old TapChanger legacy. At the time of assembly, StealthChanger used TapChanger as a reference in some areas. The projects later evolved, but old files, repositories, references, and configurations remained in the environment.

There were also remnants of:

  • old TapChanger
  • auto_speed
  • sonar
  • crowsnest
  • timelapse
  • an old camera
  • configs for unused toolheads
  • external modules in klippy/extras
  • systemd services that no longer made sense

This kind of buildup is common in advanced DIY projects. The printer may even work for a while, but the environment becomes fragile. An update can break something nobody remembered was still installed.

The diagnosis

Instead of deleting files or trying random solutions, the AI started with the right basics: logs.

The following were analyzed:

  • klippy.log
  • moonraker.log
  • configs included by printer.cfg
  • modules in klippy/extras
  • repositories installed in /home/pi
  • systemd services
  • Moonraker Update Manager
  • broken symlinks
  • external plugins
  • CAN status
  • firmware state

The main cause was incompatible external modules after the updates. The environment still had remnants and references to old plugins, mainly related to the toolchanger's earlier phase.

The fix was made conservatively: backups before editing, nothing destructive, small changes, and validation after each step.

Firmware and CAN

I also took the opportunity to update and document the boards' firmware.

The printer uses:

  • Octopus via USB-CAN bridge
  • EBB over CAN

The firmware was updated, and the builds were saved in:

/home/pi/printer_data/firmware_builds

A README was also created, documenting:

  • Octopus CAN UUID
  • EBB CAN UUID
  • Klipper version used
  • .config files
  • generated binaries
  • flash commands
  • a safe procedure for repeating the flash
  • rollback warnings

After that, CAN health was checked. The counters were clean:

rx_error=0
tx_error=0
tx_retries=0

In other words, there was no indication of a physical, electrical, or communication problem on the CAN bus.

Organizing the configurations

One of the biggest gains was reorganizing the structure of the configuration files.

Before, many things were scattered around, with old configs and active and inactive files mixed together. The simplest approach would be to leave everything inside printer.cfg, but that does not scale well. After months without touching it, it becomes difficult to remember where everything is.

The new structure became modular:

printer.cfg              # main index
core/                    # MCU and general parameters
hardware/                # fans and pins
motion/                  # steppers, probe, input shaper, path planning
thermal/                 # bed and extruder safety
toolchanger/             # StealthChanger/KTC-Easy
toolheads/               # toolhead T0
features/                # KAMP
macros/                  # macros separated by purpose
ui/                      # LEDs and display
docs/                    # operational documentation
.theme/                  # Mainsail customization

The printer.cfg became practically an index of includes.

Config files

This makes maintenance much simpler. If I want to change fans, I go to hardware/fans.cfg. If I want to review filament macros, I go to macros/filament.cfg. If I want to look at the toolchanger, I go to toolchanger/.

This organization reduces the risk of breaking something without noticing.

Version control with Git

Another important point was putting the active configurations under version control with Git.

A .gitignore was created to avoid committing:

  • passwords
  • tokens
  • large backups
  • generated files
  • old configs
  • technical junk

Now every relevant change becomes a local commit. This provides history, diffs, and rollback.

For a Klipper printer, this greatly changes the level of safety. A change made through Mainsail, the terminal, or an editor stops being an invisible change.

A more operational Mainsail

We also reorganized the Mainsail interface.

Custom links were added for:

  • Moonraker
  • Spoolman
  • post-update checklist

The macros were separated into groups:

  • Print workflow
  • Filament
  • Maintenance
  • Manual risk

Dangerous macros, such as raising or lowering the bed without homing, were isolated in an explicit group. Before, everything was mixed together and visually cluttered.

We also removed confusing parts of the interface. One example was the Z-TILT button. In a Voron 2.4, the bed is fixed, and the correct procedure is QGL. Z-TILT was legacy and was removed from the active configuration.

LEDs as machine status

The LED setup was also reviewed.

Before, many manual effects were available on the dashboard. This cluttered the interface and did not help much in real use.

The decision was to keep the led_effect plugin but hide the manual panel from the dashboard. The LEDs started being used as printer status:

  • heating
  • cleaning
  • homing
  • leveling
  • meshing
  • printing
  • cooling
  • part ready
  • standby
  • critical error

We also found real problems in macros:

  • one macro called PURGE_FILLAMENT, which did not exist
  • another called SIREN, which also did not exist

These are bugs that could remain hidden for months until someone used that exact macro.

Spoolman

We installed Spoolman, integrated with Moonraker.

It does not need hardware. It works as a filament spool manager. You register the spool, select which one is active, and Moonraker reports consumption during printing. Spoolman deducts the estimated use from the selected spool.

This helps track:

  • remaining weight
  • material
  • color
  • brand
  • usage history
  • the risk of starting a print without enough filament

Spoolman was chosen because it brings practical gains and low risk.

We also evaluated other possibilities but left them for another time:

  • Shake&Tune, for resonance diagnostics and mechanical tuning
  • Obico, for remote monitoring and a camera
  • Mobileraker, for tracking from a phone
  • reactivating a webcam, when it makes sense

The decision was important: do not install plugins just for the sake of installing them. Part of the technical debt came precisely from things that were installed, tested, and forgotten.

Documentation created

Besides the fixes, operational documents were created:

  • README for the current firmware
  • post-update checklist
  • audit of plugins and external modules
  • documentation of the new structure
  • flash and rollback instructions

This turns future maintenance into a procedure, rather than trial and error.

The real gain from AI

Without AI, this work would probably take days.

In practice, it would probably take me at least a month to reach the same result without AI. Not because of a lack of technical ability, but because this kind of maintenance requires several sessions spread out over time: investigating logs one day, understanding old plugins on another, fixing firmware later, calmly reorganizing configs, testing, documenting, and only then returning to fine adjustments. With AI, these steps were concentrated into a continuous flow, with diagnosis, execution, validation, and documentation happening almost in sequence.

Not because each command is difficult on its own, but because the whole process requires context and discipline:

  • reading logs
  • understanding dependencies
  • finding incompatible plugins
  • identifying old remnants
  • separating what is active from what is legacy
  • creating backups
  • editing configs
  • validating includes
  • restarting the right service
  • checking printer/info
  • reviewing systemd
  • checking CAN
  • updating firmware
  • documenting
  • versioning
  • repeating everything without breaking the printer

More importantly, many things probably would not even be done.

Almost nobody reviews logs preventively. Almost nobody cleans up an old plugin if the printer “seems to work.” Almost nobody documents firmware after a successful flash. Almost nobody separates macros, LEDs, the toolchanger, KAMP, fans, and motion into a structure that is truly easy to maintain.

AI helped precisely at this point. It did not just fix the initial error. It followed loose threads, found technical debt, validated hypotheses, and helped turn an aging environment into something cleaner, versioned, and documented.

Next physical steps

The software side became much cleaner, but there is still a step that AI cannot do for me: the machine's physical maintenance. Before printing confidently again, I still need to review belts, retighten structural screws, check connectors, lubricate guides/shafts as needed, clean rails, check fans, inspect the filament path, inspect the hotend, check nozzle tightness, validate the toolchanger's mechanical alignment, and run another round of calibrations. AI helped a lot with diagnosis, configuration, and documentation, but the final print quality still depends on the mechanical side being as well maintained as the software.

Conclusion

The final result was a more stable, cleaner printer that is easier to maintain.

Klipper started correctly again. The firmware was updated and documented. The environment was versioned with Git. The file structure was reorganized. Mainsail became more operational. The LEDs started representing the machine's real status. Spoolman was integrated. And the accumulated technical debt was reduced.

For me, this is a good example of practical AI use in real technical maintenance.

Dashboard

It was not “asking the chat how to fix an error.” It was using AI as a supporting engineer connected to the environment, reading logs, accessing it via SSH, making small changes, validating results, and documenting each step.

In a project like a Voron, where software, firmware, electronics, mechanics, and configuration are intertwined, this kind of assistance completely changes the speed and quality of maintenance.