Poll: Which 3D printer controller do you use, or plan to?

[626Pilot]

I think it would be interesting to get an idea of which 3D printer controllers are used by people on these forums. 8-bit controllers have dominated since the beginning, and continue to do so. However, newer ARM-based controllers provide faster processing, smoother motion control, and exponentially more RAM with which to drive displays and support new features.

[ZakRabbit]

It might be naive of me, but it seems to me that the BBB will enable us to upgrade the firmware (BBB itself) and hardware (capes and in some instances the step drivers themselves) independently. While more complex for initial setup, it is more flexible in the long run.

[KAS]

i voted smoothie because that's what I currently use, but honestly I didn't really see a difference over the Rambo.

[626Pilot]

It might be naive of me, but it seems to me that the BBB will enable us to upgrade the firmware (BBB itself) and hardware (capes and in some instances the step drivers themselves) independently. While more complex for initial setup, it is more flexible in the long run.

That's true. However, there's also something to be said for a single-board solution (namely cost). The BBP is a BeagleBone clone that has all the drivers onboard, and they were selling the six-driver version on Kickstarter for $109. That's a hell of a price! I wouldn't be surprised to see them for more than that in production.

Interestingly, the BBP runs "Unicorn" firmware, which is a BBB port of Marlin. That's the least appealing firmware someone could port, IMO - motion doesn't seem as smooth as Repetier FW, only a few values saved in EEPROM, etc. Nevertheless, it is very simple, much simpler than MachineKit. That could be used as a basis to figure out how to port far better firmware, like Smoothie or RepRapFirmware (which may have the best delta kinematics of any open source firmware out there).

i voted smoothie because that's what I currently use, but honestly I didn't really see a difference over the Rambo.

I like it for the firmware, and for being able to edit the main config in a text editor. However, it will be superseded by Smoothie 2 next year, and is not as future-proof as some other controllers (limited RAM). That's a big deal. I'm looking for my next platform, something that will have wind in its sails for years to come. I'm stuck between the BBB and Duet platforms. BBB is way more powerful, but Duet has much simpler firmware.

[bot]

KAS, in which areas did you expect the Smoothie to improve upon versus the Rambo and found that it didn't?

[Captain Starfish]

One of the main reasons I bought my Max v1 is it hit a sweet, sweet spot of build volume vs speed vs price. The printer actually came with a controller which, once I got a cooling fan on it, does everything I need to do. This mass leap to ARM based controllers leaves me scratching my head because I can't see the "problem" with the RAMBo which people are paying hundreds of bucks on upgrades to "solve".

When the RAMBo becomes a limitation to what I want to do, I might start looking at upgrades. Until then, I have too many other things to throw my money away on

[KAS]

KAS, in which areas did you expect the Smoothie to improve upon versus the Rambo and found that it didn't?

When I made the switch to .9 degree 400/rev steppers with 16 tooth pulleys, I for some reason thought the smoothieboard had 1/32 micro-stepping and got caught up in the group purchase without much research.

Ultimately I was just trying different upgrades trying to chase down that vertical banding issues.

[mhackney]

I'll pipe in here since I've actually bought and tried most of these...

BBB - I agree that a modular approach will ultimately provide more options, ability to swap bad components, etc. But one issue is there is no one stop shop at this time. Sourcing the parts from various places is a pain, especially with the limited documentation and information currently available (or at least back in Feb when I did this). Also, it is Linux, that's all I'll say about that. They are general CNC controllers, not purpose built for 3D printing.

Rambo/Azteeg X3 Pro/Arduino based - yes, they do just work. But, for delta motion the firmware (Repetier being the best at this time) is not optimal since it segments in order to work on limited processing power. That's the main trade off right now with process power and firmware. These are purpose built for 3D printing.

Duet - the delta firmware does not segment and it makes a noticeable difference. It sounds smoother running and there are way fewer surface artifacts like the banding many of us bandied about a year ago or so. The additional processing power and memory also allow for more sophisticated in-firmware delta calibration, at some point delta compensation (and I am still a believer it this based on my experience), and much more sophisticated display/input devices like the Duet Display which has a touch screen, color and a really nice menu and navigation system. Of course the process power and memory apply to BBB options too. Duet is purpose built for 3D printing.

Smoothieboard - the firmware is the nicest out there from a development perspective. It is very easy to understand and extend. All firmwares should be so straightforward. It also does have nicer motion control than the simple Arduino based firmwares but it still segments moves. In my controlled experiments I did conclude that the banding issue is much less pronounced. I also like that it has an Ethernet interface, which in theory should be more robust than the USB interfaces we struggle with. Having a text file for configuration parameters is just so simple and useful in my opinion and being able to make a backup copy of the firmware for re-flashing later is also much more useful. You can actually download and flash the precompiled binaries. This saves a lot of headaches, especially for beginners who just want something to work. The compile-upload cycle for the Arduino solutions is a PIA. The Smoothieboard and ware is a general CNC controller not purpose built for 3D printing.

I think the purpose built options ultimately are simpler to set up and maintain. All community effort goes into improving the device for 3D printing.

[626Pilot]

On GeneB's advice, I contacted Mark of UltiMachine to ask whether they might be working on a RAMBo successor. This is posted with Jason's permission:

We have a 32bit ARM successor in the works. It uses the Atmel SAM3X processor and has 5 DRV8825 stepper drivers. There are additional GPIO pin headers that can be used to manually wire up an external stepper driver. We will have the board available for purchase in about month. I am sorry this does not really satisfy the requirements for an all in one Diamond hot end printer controller board. The plan is to eventually make an adapter board that provides additional stepper drivers.

If you have any ideas or other questions I would be happy to help.

Regards,
Jason
UltiMachine

SAM3X suggests to me that it will be like the Duet (84MHz, 64+32K RAM). I wouldn't be at all surprised to see these in the next iteration of SeeMeCNC's printers.

[Nylocke]

I currently only have running cartesian printers (My Ultimaker and another one I've been working on for a while) so they don't need all the fancy power and features of the higher end controllers. When I get my MAX back to running I want to put something better than whats currently available into it. Smoothie is okay, but there are certain features it lacks, namely the ones Pilot has problems with, and the lack of 32X drivers on the "official" board.

I agree with Michael's conclusion on BBB. The concept is great, and I was wanting to get one for my MAX a few months back, but there isn't a one stop shop, it runs on Linux (not that thats bad, I just don't know how to use it currently), and the software is more painful to setup than Smoothie or Repetier/Marlin. Until someone comes out with something "really great" I won't be putting time or effort into getting my MAX running.

[Polygonhell]

I've built and written software for a couple of motion controllers, nothing as comprehensive as what's in general use, but I still use one of them on one of my cartesian printers.
I still don't think Linux is a good solution for realtime systems, even with "kernel enhancements". The issue with most of the higher end arm boards is that half the features aren't available outside proprietary Linux drivers, so your kind of stuck with it.
I've been messing with FPGA based solutions recently, they'll trivially generate step pulses with more accuracy that any uControlller could approach, (not that it much matters). The issue becomes where you draw the line between what's "hardware" and what you do either in a softcore or an associated CPU.

[626Pilot]

Based on what I see here and eleswhere, there seems to be a three-way schism.

The majority of 3D printer controllers are running Marlin or Repetier on 8-bit, 16-20MHz boards (mostly 16MHz) with 4KB of RAM. That will probably remain the case for the next couple of years or so. Their advantage is market share, and... nothing else. They already strain to keep up with delta calculations, and for our purposes offer very little in the way of being future-proof. New features could potentially compromise the time-critical code, as has happened in the past.

Then, there's the "fantastic firmware, moderate CPU" camp - Smoothie and Duet. These are the best open-source 3D printing firmwares, as far as I can tell. However, they run on CPUs that are not particularly future-proof. Smoothie runs on a processor with 64K RAM, and Duet runs on a slightly slower processor with 96K RAM. Their advantage is twofold: better firmware, and low complexity. As with the 8-bit boards, there is no separate OS. The firmware has its own kernel, and is fully upgraded in one step.

Finally, there's the "problematic firmware, fantastic CPU" camp. In other words, BeagleBone Black. These boards have a main processor that runs at 1GHz, two secondary processors running at 200MHz (good for kinematics and step generation), and 512MB RAM. The downside is that it runs MachineKit on top of Linux, so you're getting your software from two different places. bubbasnow gave me some resources concerning where to find everything. I think some users are scared off by the fact that it runs Linux instead of being a "pure firmware" solution, where the entire board runs one piece of software with no separate OS. How much that matters in practice, I don't know. Someone else would have to chime in. I think that if the firmware provider supplies an OS image and keeps that updated with patches, etc., it's probably okay.

My dream platform would be a single-board BBB clone (like the BBP) running Smoothie on the bare metal, without a separate OS.

[Polygonhell]

As I said the issue I have with linux is it's not an RTOS, even with the realtime patches that are in Machine Kit it's still not an RTOS, you simply can't guarantee response time to an event. Same's true for Windows which is even worse. Having said that a lot of people do a lot of machining with Linux CNC and Mach3 using parallel ports, relying entirely on that OS latency and they both manage just fine.

The PRU's offset that to some extent in the TI chips used in the BB, but the documentation is sparse and the tools were pretty rudimentary when I last looked at them. TI does provide a direct no OS interface for the chips, but If you want to use the graphics accelerator, the only option is Linux, because the driver is provided as a binary by Imagination Technologies.

LPC 1767/8's or other similar arm processors from various manufacturers are plenty fast enough for what we need to do including the delta calculations (though you need to be aware of the limitations), the only really memory hungry thing in most of the firmwares is the Ethernet interface. I guess a web interface would be a nice to have built in, and though it's certainly doable on even a 1767, you'd probably want more memory.

[geneb]

I'm surprised nobody has looked at a Raspberry Pi running RiscOS instead of Linux.

g.

[JFettig]

I'm surprised nobody has looked at a Raspberry Pi running RiscOS instead of Linux.

g.

Looks like Windows 3.1 combined with Windows 95

How will that control a 3d printer?

[geneb]

Hehe. If memory serves, it's a cooperative multi-tasker, which brings it closer to an RTOS. Basically what it means is that unlike a pre-emptive multi-tasking system like Linux or Windows, the operating system doesn't interrupt a running process in order to hand over control to a different process. The currently running process has to specifically return control to the process scheduler so it can kick off the next process (or process slice) in line.

If you've got a printer controller that only gives up control when it's "safe" to do so, you've got a defacto RTOS application on your hands.

g.

[Captain Starfish]

FWIW LinuxCNC has just dropped a new version which can be installed direct onto a BBB.

Don't know how well it works with 3D printing, but given that it supports a hell of a lot more G-codes than our printers use it should be fine.

The whole "linux/windows are not RTOS" thing has been raging on cnczone this week: my take on it is that your jitter is most likely caused by colliding events (two separate threads at the same priority trying to do something at once). As the processing speed goes up, the chances of these collisions drop and really, on modern hardware if it's dedicated to the sole purpose of running the machine then the chances are bugger all and any operating system effectively becomes realtime.

That said, there's a big difference between a year-old PC and a BBB in terms of power so I'd be interested to see how it goes.

[Polygonhell]

It's not really multiple threads that are the issue, though both Windows and Linux have less than ideal handling of thread quantums for realtime systems. It's more about how interrupts are handled by kernel level drivers and threaded through the OS to become system events received by user mode threads.
RTOS' give hard guarantees, and thread scheduling is also usually dealt with very differently.

Either windows or Linux is a fine OS for CNC control when paired with a controller with a queue that's handling the hard real time stuff, but you have to accept potential latency issues and EStop has to be handled carefully.

You can certainly see the difference on a scope in the quality of pulse train from say Mach 3 over a parallel port and a smooth stepper (which uses an FPGA to generate the pulse train). But for milling there are far more critical issues, like how the path planner enforces Acceleration and Jerk constraints and what errors it introduces to do so.

[Eric]

The majority of 3D printer controllers are running Marlin or Repetier on 8-bit, 16-20MHz boards (mostly 16MHz) with 4KB of RAM. That will probably remain the case for the next couple of years or so. Their advantage is market share, and... nothing else.

In the case of the RAMPS combo, the price! The RAMPS board is cheap because it's got nothing expensive on it. The ATMega2560 is cheap because its generic and produced in volume. Ditto for the Pololu type stepper drivers. Total cost under $50 if you're any good at shopping. And personally, I like being able to replace a $3 driver rather than having to swap/fix an all-in-one board. But maybe I'm just strange that way.

[626Pilot]

In the case of the RAMPS combo, the price! The RAMPS board is cheap because it's got nothing expensive on it. The ATMega2560 is cheap because its generic and produced in volume. Ditto for the Pololu type stepper drivers. Total cost under $50 if you're any good at shopping. And personally, I like being able to replace a $3 driver rather than having to swap/fix an all-in-one board. But maybe I'm just strange that way.

This is true.

Hehe. If memory serves, it's a cooperative multi-tasker, which brings it closer to an RTOS. Basically what it means is that unlike a pre-emptive multi-tasking system like Linux or Windows, the operating system doesn't interrupt a running process in order to hand over control to a different process. The currently running process has to specifically return control to the process scheduler so it can kick off the next process (or process slice) in line.

The Pi can run RTLinux, which will provide microsecond-accurate timing. (Maybe not one microsecond on the Pi, but certainly around there somewhere.) Stepper pulses are around 1-2 milliseconds wide, so a microsecond-accurate interrupt will still be an order of magnitude faster than needed! I saw one guy - ONLY one guy - doing 3D printer firmware on a Pi for a school project. Probably no one else has bothered because there's no shield for it with enough stepper drivers.

This makes me think there's a market opportunity for someone to produce a stepper shield (with more than two drivers - the most I could find!) for the Pi. If only there was some good firmware, right?

The Pi is also $15-30 cheaper than a BeagleBone Black, depending on which model and where you get it from. The BBB's PRUs are certainly a nice solution, but - was it even worth porting MachineKit's control routines to run on them? If RTLinux runs on the BBB, then I honestly don't think it was!!!

[Eric]

GPIO Ports is an area the Pi designers didn't think enough about. Even the latest version of the Raspberry Pi has half the native GPIO ports that an Arduino Mega has. So the first thing any Pi solution needs to deal with for a significant number of driver and mosfet outputs is port expansion. And support code for the expansion method chosen.

[626Pilot]

GPIO Ports is an area the Pi designers didn't think enough about. Even the latest version of the Raspberry Pi has half the native GPIO ports that an Arduino Mega has. So the first thing any Pi solution needs to deal with for a significant number of driver and mosfet outputs is port expansion. And support code for the expansion method chosen.

There are ~25 GPIO pins. If that's not enough, shift registers would be the obvious choice. They cost almost nothing, have response times in the single-digit nanosecond range, and you can chain them. Should be clean enough to control as many steppers as you like on a few IO lines. You could use digipots to control the motor current. Those don't cost much either.

[mhackney]

I also think that purpose built CNC/printer controller solutions are more desirable for a number of reasons. For one, there are no competing interests on features within the dev community on either the h/w or s/w. Also, three is no unnecessary h/w or s/w functionality (like video ports, etc) raising complexity and cost. Having an open source community familiar with the end product (i.e. 3D printing) is also critical in my opinion. The linux solutions out there were developed primarily for CNC machining and robotics. Similar but not the same.

[626Pilot]

I think the HDMI port is actually kinda nice! If you use a screen with a touch digitizer, you can have a phone-like UI. I think people will expect more stuff like that in the future, especially as adoption increases by people who aren't as tech-savvy as the sort of people who post here.

For people to take a BBB solution seriously, the Linux part would have to be as transparent as possible. From what I'm hearing, a lot of people don't want to have to deal with learning a whole new OS just for the sake of using a 3D printer. I think that could reasonably be done - you hand them an SD card image and tell them to burn it using whatever point-and-click software they like, and that's the end of that.

The thing is, the simpler controllers (Duet, Smoothie) are running on CPUs that baaaaaarely have enough RAM to do fancy things with today. What does that look like in two years, as more features are added? My calibration routine is fairly RAM-intensive. What if someone wants to add support for "normal" (not linear) delta printers, SCARA, Simpsons, etc. kinematics? What if they sent me one so that I could make my calibration work with their geometries as well? All that stuff would take more RAM, and the additional code would take up more flash memory. Suppose someone comes up with a SUPER nice menu that runs on a $40 touchscreen TFT from AdaFruit, and it looks like heaven, and it's the most usable interface on any 3D printer ever. Suppose it requires 20K of RAM that simply isn't there unless you turn off EVERY other feature there is. What if you want to stream video from a camera, but you need 32K for a framebuffer - and 32K is not just laying around?

That's why I haven't written off the BBB. In some ways, it's more of a pain in the ass. However, there's no denying that 0.5 gigabytes > .0000625 gigabytes. It's not that much extra dough, either. An A-model Raspberry Pi is $30, and has way more than just a CPU on it.

Also, the Smoothie-compatible boards have pulled ahead of RAMBo, etc. in the poll. That's impressive. When I started the poll, I thought almost everyone would answer that they had an 8-bit controller. SeeMeCNC, if you're reading this, you might wanna talk to UltiMachine about their RAMBo successor. Survey respondents are self-selected, so this is not a scientific poll. However, there are enough samples that it's increasingly hard to ignore. There's also the "do you want to upgrade" question - seven yea, one nay. People seem to want 32-bit controllers!

[mhackney]

Good point in the HDMI, bad example on my part!

Lots of consumer devices (almost all TVs for instance) use Linux and the user experience is completely transparent. This could be done for 3D printers too if a group/open source project wanted to take it on.

I think smoothie is pulling ahead, the community is obviously gaining momentum. Successful Open Source depends on a large base of users and developers and that takes time to create. Smoothie is coming into its own after a few years of simmering (which is normal). RAMBo and the others all rode the wave of the existing firmware Marlin and Repetier primarily. It's actually pretty impressive that Smoothie with a completely new firmware and hardware platform has been able to penetrate quickly. Part of that is due to the Arduino based platforms running out of steam, especially for delta printers.