No stranger to the world of 3D printers, [Elias Bakken] from the [Intelligent Agent] workshop has released a new controller board called Recore. The typical 3D printer has a dedicated controller which handles the real-time aspects of driving stepper motors. Many setups also have a second computer, often Linux-based, which is dedicated to supporting tasks like running an Octoprint server and interfacing to a digital camera to monitor print progress remotely. [Elias]’s design merges these together into one compact 12 x 12 x 4 cm package.
The Recore board is powered by an AllWinner A64 system on chip (SoC) which packs four ARM Cortex-A53 AArch64 cores running Debian Linux. The applications include Klipper, a project we wrote about when it was first introduced, and the OctoPrint print server. “But Linux is not a real-time operating system”, we hear you cry, “and controlling stepper motor drivers from an A64 SoC is just asking for trouble”. [Elias] could have addressed this problem by putting a secondary microcontroller on the board, but he found an even more elegant solution instead.
It turns out that there is already a secondary microcontroller hidden in plain sight, integrated into the A64 itself. See that small box labeled AR100 at the top of the block diagram? Meet the AR100, a controller originally intended to manage low-power operations of the A64. It is an OpenRISC 32-bit OR1k processor. But the AR100 is extremely underutilized, and [Elias] takes good advantage of this by repurposing it to those real-time tasks associated with a 3D printer controller. Watch the short video down below to learn how he solves a few of the nitty-gritty implementation details such as timers and communicating with the Linux processors. You might learn some tips from the other short videos in the series featuring some interesting debugging and problem solving sessions. There is a project GitHub repository and a Wiki full of good information and testing results.
[Elias] has a long history of building printer controllers. While his last one had to be abandoned because of manufacturing issues, he learned from that experience. Manufacturability was a top priority in the design of the Recore. We’re jealous of the well-appointed [Intelligent Agent] facility in Norway, but even more so of the nomadic lifestyle that [Elias] appears to enjoy — in his videos, he can be seen working from far-flung locales such as a tropical island resort and a laboratory floating in high Earth orbit. We’ve featured [Elias]’s projects in the past, including the Replicate 3D printer controller, a semi-automatic liquor cabinet, and the dog-operated treat dispenser.
Traditionally, 3D printer control boards have used simplistic 8-bit microcontrollers to command the stepper drivers and ultimately move the machine where it needs to go. Newer boards have switched over to 32-bit microcontrollers, but they’re still relatively limited computationally. Because of this, a Raspberry Pi running OctoPrint is usually used to provide more complex features such as remote management and live video.
Looking to combine these different devices into a single all-in-one board, [pkElectronics] developed the Sigmoid S7P. With an STM32 microcontroller, TMC2209 stepper drivers, a Raspberry Pi Compute Module 4, and plenty of room for expansion, it promises to be a drop-in upgrade for essentially any 3D printer running on an open source firmware that could be ported over.
According to [pkElectronics], the idea for the Sigmoid had been floating around for several years, but never got off the ground due to the difficulties in dealing with the SO-DIMM interface used by previous iterations of the Compute Module. But with the switch to smaller and denser connector for the CM4, the board finally started to take shape.
There was a time, not so very long ago, that buying a reliable 3D printer was a fairly expensive proposition. Many chose to build their own printer instead, and for a few years, we were flooded with very impressive custom designs. But as you might expect, with the prices on decent 3D printers now having hit rock bottom, the custom builds have largely dried up.
Arguably, the only reason you’d build rather than buy in 2020 is if you want something very specific. Which is precisely how [Joshendy] ended up building the Big F… Printer or BFP. No doubt the F stands for Fun, or Friendly. Either way, it’s certainly something special. With a 300 mm³ build volume and heavy-duty Z axis, this fully enclosed CoreXY machine is ready to handle whatever he throws at it.
It did take [Joshendy] a few attempts to get everything the way he wanted though. In fact, the prototype for the machine wasn’t even CoreXY, it started as an H-Bot. In his write-up he goes over the elements of the BFP did that didn’t quite live up to his expectations, and what he replaced them with. So when wobbly leadscrews and a knock-off V6 hotend both left something to be desired, they ended up getting replaced with ball screws and an authentic E3D Hemera, respectively.
To control this monster, [Joshendy] is using OctoPrint on a Raspberry Pi and a BigTreeTech SKR Pro running Klipper. OctoPrint gives him the ability to control and monitor the printer remotely, complete with a camera mounted inside the enclosure to keep an eye on things, while the Klipper firmware on the SKR board pushes all the computationally expensive aspects of 3D printing onto the vastly more powerful ARM chip in the Pi. The end result is faster and more accurate control of the steppers through the TMC2130 drivers than would be possible otherwise.
Although we tend to think of 3D printers as high-tech toys, most of them are not especially powerful in the brain department. There are some exceptions, but most 3D printers run on either an 8-bit Arduino or some Arduino variant with a lot of I/O. There are a few 32-bit boards, but if you grab a random 3D printer, its brain is going to be an 8-bit AVR running something like Marlin or Repetier. It isn’t uncommon to see a Raspberry Pi connected to a printer, too, but — again, in general — it is a network interface that handles sending G-code to the 8-bit controller that runs the stepper motors. Would it make more sense to do things like parse G-code, map out curves, and set accelerations in the relatively powerful Raspberry Pi and relegate the 8-bit AVR to just commanding motors and heaters? [KevinOConnor] thinks so, and he wrote Klipper to prove it.
Klipper is mostly written in Python and it does most of the functions of traditional 3D printing firmware. It communicates with the onboard microprocessor by providing a schedule of when to do what tasks. The microprocessor then handles the timing and things like motion control for the axes and extruder. Klipper can control multiple microprocessors with no trouble and keeps them in synchronization, so you could have a processor for your extruder and one for each stepper, for example. You can use Klipper with a Cartesian machine, a delta, or a Core XY-style printer.