In the previous article, I described how an old Graber i3 came into my possession and the problems I encountered while trying to bring it back to life.
At first glance, everything seemed straightforward: the main components were there, the electronics worked, and the motors moved. All that remained was to configure everything and start printing.
But the configuration turned out to be much more difficult than I expected.
The print bed, in particular, took a great deal of time.
Marlin and the Endless Bed Adjustment
Initially, the printer was running Marlin.
It's a well-known and widely used firmware for 3D printers, so I had no reason to abandon it right away.
I tried to adjust the mechanics, achieve the correct nozzle position relative to the bed, and get a consistent first layer.
But I kept running into the same problem.
In one part of the bed, the nozzle was at the right height. In another, it was either too close to or too far from the surface.
Adjusting one area could make the result worse somewhere else. I had to readjust the bed, check the gaps, and try printing again.
Of course, Marlin provides tools for compensating for bed irregularities, including Bed Leveling. But with my particular configuration, I couldn't get the results I expected.
Perhaps I had configured something incorrectly or hadn't fully understood the firmware's available features.
Nevertheless, time kept passing, and I still couldn't get a reliable first layer.
At some point, I realized that instead of continuing to experiment with Marlin, it was worth trying a different approach.
Discovering Klipper
That's when I started looking into Klipper.
The main difference that caught my attention was its architecture.
In a traditional Marlin setup, the main control logic runs directly on the printer board's microcontroller.
Klipper takes a different approach: some of the computations are performed on a separate Linux computer, while the microcontroller executes the prepared hardware control commands.
A Raspberry Pi or another suitable device can be used for this.
But what interested me wasn't so much the architecture itself as the configuration possibilities.
In Klipper, the printer configuration is stored in text files. Many parameters can be changed without rebuilding the firmware and flashing the controller every time.
The system also provides convenient tools for calibrating the mechanics and the print bed.
After numerous attempts to achieve acceptable results with Marlin, all of this looked very appealing.
I decided to give it a try.
First Run on Raspberry Pi
I started with a Raspberry Pi.
It was a logical choice: I was already familiar with the device, and there was plenty of documentation and installation examples for running Klipper on Raspberry Pi.
After installing the necessary components and configuring communication with the printer's control board, I had a working system.
Now I could change parameters through configuration files, restart the relevant components, and immediately check the results.
I found this workflow much more convenient.
I no longer had to keep going back to the firmware source code, rebuilding the project, and flashing the board for every configuration change.
Gradually, I began working through the motor configuration, movement limits, heater settings, and bed calibration.
Of course, switching to Klipper didn't automatically make the printer accurate.
The mechanical problems hadn't disappeared, and the bed still needed attention.
But I now had more convenient tools to continue working with.
Why Use a Raspberry Pi?
After a while, I remembered that I had an old TV box lying around unused.
It was an ordinary television set-top box that was no longer being used for its original purpose.
That gave me an idea: why keep a Raspberry Pi permanently occupied when I could try adapting this device to control the printer?
Essentially, Klipper needs a computer capable of running Linux, executing the necessary software components, and communicating with the printer's controller.
Raspberry Pi is a popular option, but certainly not the only one.
So I decided to give the old TV box a second life.
There was something almost symbolic about it: while restoring an old 3D printer, I also found a purpose for another device that had been sitting unused.
Linux on a TV Box
The first step was getting the TV box to run Linux.
TV boxes usually come with Android and aren't designed by their manufacturers to control 3D printers.
However, some of them can run alternative operating systems.
After installing Linux, the box became a small computer that I could use to run Klipper.
All that remained was to install the necessary software components, transfer the printer configuration, and verify communication with the control board.
In the end, I was able to stop using the Raspberry Pi and move control of the Graber i3 to the TV box.
This was also a good solution because the box now had a permanent purpose.
Unlike the Raspberry Pi, which I might need for other experiments, the TV box was now dedicated entirely to the printer.
A Permanent Control Computer
After getting everything running successfully, I decided to mount the box directly on the printer.
This meant it was no longer a temporary device connected only during configuration.
The TV box became a permanent part of the Graber i3.
The Klipper software ran on a separate Linux computer, while the printer's control board continued to handle the motors, heaters, and other electronics.
I liked this approach.
On one hand, I could keep the existing control board. On the other, I gained the ability to develop the software side without replacing all the printer's electronics.
And once again, old hardware had become useful.
Klipper Doesn't Fix Mechanical Problems
After switching to Klipper, working with the configuration really did become easier.
But one of the main problems that had started this whole process hadn't completely disappeared.
It was still difficult to adjust the bed manually and achieve an equally good first layer across the entire surface.
Even with more convenient calibration tools, I couldn't achieve the accuracy and repeatability I wanted.
Gradually, it became clear that software adjustments alone wouldn't solve the problem.
I needed a more reliable way to measure the position of the bed surface, along with further changes to the printer's construction.
Later, I installed a sensor that provided repeatable measurements and made it much easier to level the bed at four points.
But that was already the next stage of the upgrade.
The Result
Moving from Marlin to Klipper became one of the important stages in restoring the Graber i3.
I gained a more convenient way to configure the printer, the ability to change settings without constantly reflashing the controller, and tools that made further experimentation easier.
Using the old TV box also freed up the Raspberry Pi and turned an unused television set-top box into a permanent control computer.
That doesn't mean I consider Marlin to be bad firmware. It has its own advantages, and a huge number of printers run successfully on it.
It's simply that for my Graber i3 and the problems I was trying to solve, Klipper turned out to be a better fit.
However, the software side was only the beginning.
There was still the bed sensor to install, changes to the Z-axis motor control, motor driver replacements, and mechanical issues to fix.
Those are the upgrades I'll cover in the next article.