1. About
  2. Features
  3. Explore

Over the times I hear people saying delta inverse kinematics push atmega2560 to limits. I see in my local supplier Arduino Due and RAMPS-FD is the cheapest 32bit alternatives. But there's not much documentation on it so any opinion or personal experience are welcomed.

  • is it really 2560 based electronics so laggy that printing quality is compromised?
  • does Marlin4Due has a good support for auto calibration?
  • anything else to caution against besides a ramps1.4 is a no-no?

(I'm planning my first delta. 2560 seems to work perfectly with my previous xy bots though. )

1 Answer 1

An 8bit Atmega can provide bare-bones delta performance with Marlin (eg 40mm/s print speed) or pretty good performance with Repetier (due to more optimized algorithms). For a small and simple delta like a bare-bones Mini Kossel, 8bit may be fine. If you want to do high-speed printing or use any of the fancier features, you should go with 32bit.

The big issue with 8bit comes up when you want to do something that taxes the MCU. Delta kinematics already add a lot of extra math on top of all the normal printer functions like command parsing, motion planning, and heater control. For example, adding any of these to an 8bit Delta can cause issues:

  • Bed tilt compensation "auto-leveling" -- the coordinate space rotation transform adds a lot of extra floating point calculations to every movement segment. That really taxes the 8bit Atmega since it does not have native floating point support. (Note that pre-print auto-calibration such as in the RichCattell Marlin fork is not the same as bed tilt compensation and does not add any run-time processor load.)
  • Full graphics LCDs -- refreshing the LCD screen for animations and status reports takes a surprising amount of horsepower. 8bit Marlin is widely known to suffer from stuttering and print quality issues when running a GLCD on a delta.
  • Highly faceted (smooth) curves, particularly over USB -- the high rate of gcode command processing sucks up a lot of clock cycles, particularly in firmwares that run USB comms as a top-priority interrupt.

What the Due (or other 32bit board option) does for you is de-bottleneck the MCU so you can push the printer harder or utilize features that add processor load. Here's why they're so much better:

  • In simple clock speed terms, the SAM3X8E in the Due/Duet/Alligator/etc is about 5 times faster than the Atmega 2560, and the LPC1769 in the Smoothieboard/MKS-SBASE/etc is about 7 times faster. But they're actually MUCH higher performance than clock speed alone would suggest, because the 32bit architecture and native floating point support mean far fewer clock cycles are required for complex calculations.
  • They also have more RAM, meaning the the firmware can manage more features and look farther ahead when motion planning.
  • They also have more program space, meaning the firmware can, if desired, be compiled as a single full-featured build that covers all possible printers (as RepRapFirmware and Smoothieware do) and thus end-users don't have to edit and compile code in the Arduino IDE to configure the firmware. The Atmega line requires hundreds of conditional compile statements in the firmware to exclude unused features from the binary to get the memory footprint down.

All that said, the switch from an 8bit Atmega AVR to a 32bit ARM Cortex-M3 is still just an upgrade from a late-1990s processor to an early-2000s processor. Neither is "modern" by any stretch. (For example, the BeagleBone Black used by Redeem and MachineKit utterly blows away the Due in processing power and memory. But those options have steep learning curves at the moment.) The Due can still be bogged down by printing very fast with lots of features enabled. It's a big upgrade on an Atmega, but I predict it's going to be replaced by much faster controllers within the next few years. Announcements of upcoming next-gen controller boards are already trickling out.

To summarize, the answer is yes, a Due-type board is a good buy if you want a high-performance printer. It will meet 99%+ of user's needs today. But it will be replaced in a few years, just like the Atmegas are being replaced now.

As for specific Due shields, I strongly recommend NOT going with RAMPS-FD. It was cloned for sale by Asian companies before the design was finished, which seemingly caused the original designer to abandon it before working out all the bugs. RAMPS-FDv1 has some nasty design flaws such as heaters turning on while flashing firmware. RAMPS-FDv2 is better, but can experience unreliable and oddball behavior due to unresolved issues in the circuits intended to make it compatible with both 3v3 boards like the Due and 5v boards like the Mega. (For example, the thermistor voltage reference circuit needs modifying to work right, and there appears to be timing issues in the 3v3-5v level shifters.)

RADDS is a good Due shield. It is a simpler, more reliable, more compact version of RAMPS-FD. It is very popular in Germany and has recently (late 2015) become available for sale in the US.

I also recommend purchasing the Due R3-E instead of the regular Due R3. Anecdotally, the "E" version appears to eliminate some firmware bootup issues that can occur when the board is first powered at lower than nominal voltage.

One possible downside to the Due is that Arduino just announced they are no longer manufacturing it. So all new Due boards from here on will be made by 3rd parties. That's not necessarily bad, since it's open source and many other companies will surely continue making them, but there won't be any more made by Arduino.

For single-board options using the same SAM3X8E processor as the Due, the Duet 0.8.5 is becoming quite popular. (It runs RepRapFirmware, which has some great Delta features.) The Alligator runs Repetier. There are several other beta/experimental/development boards in the works too. The community appears to be moving towards the Due and Due-compatible boards over the other various options.