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.
“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.”
Just a little stretch. :D
This is the prettiest board I’ve ever seen!
Great to see this combination of octoprint, camera and print controller! The combination is definitely the Minimal Viable Product going forward!
I would love to see ARM address this use case directly. It would be great to have a no compromise solution with an order of magnitude more performance.
While the state of the art in 3D printing is always advancing, 3D prints are still in the dark ages in terms of performance.
Imagine having all prints done in under a minute instead of hours.
ARM has the Cortex-R designs. My understanding is that they are quite widely used; but don’t tend to show up in hobbyist applications as much because they don’t do support for friendly general purpose OSes as well as the Cortex-A stuff that shows up in all the phones, tablets, STBs; and cheerful little dev boards (even the biggest and most recent Cortex-Rs have optional MMU support, rather than default) and they aren’t as cheap as the Cortex-Ms (albeit considerably more capable) that people who want to do close-to-the-metal microcontroller stuff on ARM typically use.
Lots of stuff (I think even desktop ryzen processors?) have one or more cortex R cores crammed into it for similar reasons. Sometimes it’s accessible to the person using the application processor, sometimes it’s not (running firmware for bootstrapping, or secure enclaves, or…)
I’d love to see more builds/designs like this one, though they need a unique set of skills (comfort at a variety of levels of the stack in great detail)
As far as my understanding goes (from working with 3D printers for a while), their performance limitations do not come from limits on processing power. Those went away completely with the introduction of Klipper and/or 32-bit controllers. Rather, the issue stems from physical properties of the plastic – there is a minimum amount of time the plastic needs to bind to a layer and then cool down, and there is relatively little that can be done about this. You can add more cooling fans or use a different material, but that will only do so much.
You can increase print speed to 2,000% and the printer will probably do its motions perfectly at an insane velocity (even considering motor limitations), but all you’ll get from it is spaghetti. If you want a real increase in print speed, you need to consider alternate printing technologies like SLA.
You are right. There are physical limits to the used materials. Doing a real revolution in printing speed will require revolutionary materials.
There are limits on how much PLA or ABS you can push trough a nozzle. At a certain point you would need to heat it up above temperatures where it starts to break down fast. So you cannot go faster on that area. Even if you can lay it down accuractly at those speeds. And these limits aren’t even that much higher then what most printers currently already can do.
It also needs time before it’s properly bonded with the previous layer. Which is why PLA works so well, it bonds very easy, and you can cool it down very fast after that. There generally isn’t a thing as “too much cooling” with PLA, while you can cool ABS too fast for example and then it doesn’t bond well.
Going from the silly 8bit AVR to a nice 32bit ARM gave some nicer motion profiles, which results in a slight improvement in printing quality and noise reduction. But it’s not a huge leap in overal performance. Just like improving the acceleration of your car won’t do much on long distance travel as you are still limited by the speed limit.
I’ve said this to people before. 3D printers haven’t changed much. The main difference between my first generation Ultimaker (kit version) and a shiny new Ultimaker S5 is on the usability aspect. Easier to use interfaces, less difference between machines (=more optimized default settings) network connection, monitoring, printer pooling. Those kinds of things. But print speed and quality are not that far off from each other in the first gen Ultimaker to latest generation Ultimaker.
I agree with your opinion that materials hold 3d printing speeds down but I think you’re wrong when it comes to controlling the hardware.
Your long drive analogy is completely flawed. Yes you’re ultimately limited by speed limit but you can disregard your car acceleration only if you’re driving on the straight line. The more twisted the road is, the more acceleration you need, to the point that without acceleration you could newer reach speed limit. When it comes to 3d printers in terms of cutting print times were a long way of the limits. As the racing cars are lightweight, stiff, accelerate as fast as they can and have competent driver on board so the 3d printers should have lightest print head, stiffest frame and motion system, a lot of torque in the steppers and electronics with enough processing power and clever algorithms to control it well.
Newer printers also tend to be stiffer than the early kits, better able to take a faster print head movement. And often run ‘silent’ stepper drivers – which is lovely.
But your quite right the processing speed isn’t the biggest limitation on FDM printers, its the power and stiffness of the whole machine, and the need for the extruded filament to cool sufficiently for the next layer.
Increasing extruder flow is the kind of thing that E3D’s Volcano is good at: Rather than increasing temperature to get more flow, it increases the length of the meltzone. This gives the filament more time to come up to temp for a given volumetric rate than the more typical V6-derived nozzles and heaters.
At 0.4mm, the rate that a volcano can consistently melt filament greatly exceeds the mechanical abilities of most Cartesian printers.
https://www.youtube.com/watch?v=_A8HxlQuhjM
I’d be happy with this kind of top speed to be honest.. If they make this sort of thing the norm/cheaper, it would be enough for most people.
Many of the present limits of 3d printing speed are overcome here:https://www.youtube.com/watch?v=p5CgmgXE5bc
“But Linux is not a real-time operating system”
Correct, Linux is a kernel.
For Linux, there is a real-time patchset available; https://rt.wiki.kernel.org/index.php/Main_Page
It works somewhat, but it’s reliant on hardware and software playing together nicely – which doesn’t happen in practice.
I used a Posix RTOS called Lynx back in the 90s in a big VME system. Just searched, they’re still around, but this is a commercial not open source product.
Making use of underutilized peripherals? Lovely!
Wow! An honest to goodness hack!
You could also use one of the ARM cores as a ridiculously overpowered realtime core.
see https://www.raspberrypi.org/forums/viewtopic.php?t=228727
thanks! this is exactly what i was wondering about.
if there’s no way to redirect general interrupts away from the ‘real time core’, then it’s a non-starter, impossible to achieve. IMO the sine qua non for realtime programming is implementing a delay by counting the clock cycles per instruction and multiplying by the cpu clock, which is only possible if you know exactly what interrupts are in play. i guess cache / superscalar execution / branch prediction (iow, spectre/meltdown) etc would already get in the way of that. so it was probably just a pipe dream anyways. you may be able to make it work for a lot of common tasks but it won’t come close to the capacity you take for granted in a real microcontroller.
i do wonder how widely spread this global irq enable problem is. i’m inclined to blame raspi for making a hash of interfacing with the broadcom chip and not leaving enough clues for us to unravel their mistakes. but i don’t know anything about interrupt controllers in multi-core CPUs..
Interrupts and task scheduling are always a pain on any CPU, at least it seems that way when ‘real time’ is the goal. So while the Pi might not be as documented as we would like, that is not really an uncommon failing from what I’ve seen – but that is kind of fair enough, real time isn’t what CPU are really for.
That said the shear performance of a Pi (and similar) means it usually can manage microcontroller and small FPGA type loads, definitely not the ideal tool for all situations though.
Realtime core doesn’t mean jack if the GPIO is on a shared bus with a non-realtime stuff. Like the video clearly states.
Nice use of little known peripherals of an ARM SoC, but that isn’t for me. For years now I just support open hardware, which this board isn’t. It’s a shame, because the idea of incorporating a Linux computer and a 3d printer microcontroller seems to be executed very nicely here.
Aside from the project, this was a really clean and well-produced video. Anyone know how he produced the graphics used in the video? I really liked the animated sketches with accented parts. I’d like a walk through of the video process itself.
Graphics done in Inkscape and animated with Davinci Resolve!