Going to build a cartesian with the bed on the Z. I thought about corexy a lot, but I prefer the simplicity that comes with a cartesian, and printing slower doesn’t bother me. Heck, I don’t even want to deal with bowden, so direct drive will slow things down as well. Now I’m searching for a controller board, and I’ve been thinking… besides the advantage of being able to change configurations easier trough the config files, do I have any other advantages for choosing 32bit architecture ? Speed is definitely not going to be one of them for me, an 8 bit processor will be more than capable of driving the cartesian at low to medium speed.
What are you defining as “cartesian”? Mendel-style is cartesian, Ultimaker/Ingentis style is cartesian, Crane-style is cartesian (Printrbot and others). I’d consider CoreXY and H-Bot’s to be cartesian as well. Only difference between CoreXY and a normal cartesian is that you’re basically rotating the control scheme 45 degrees.
Only ones not really considered cartesian are Deltas, Polar, and Scara
He said bed on the Z so I think he means Ultimaker style. I have to say I’ve been considering designs for a new printer (currently I have a Mendel 90) and I’ve come to the conclusion that a basic bed on the Z design with direct drive is probably the way to go as well.
His question was about the advantages of the 32 bit architecture however which is something I’d like to know about as well.
By quantity in the wild, as far as I can tell, Mendel style Cartesian printers are #1 and Darwin style (namely Replicator 1/2/2x and clones) Cartesian printers with XY gantry / Z bed are #2. Ultimakers are nice but they’re much more complex than a Replicator Cartesian.
So yeah, I am building a Darwin style cartesian, to be more specific.
So regarding the controller, seems that besides some minor extras which is great to have but not a must… I could have the same print quality on a slow printer with an 8 bit controller as well ?
32bit lets you run higher speeds AND more features. For example, running a GLCD and probe autoleveling and delta kinematics is too much for an 8bit controller. If you just want a vanilla Cartesian printer without anything fancy, then yeah, 8bit is fine. Once you start adding processor loading you really ought to upgrade.
If you do to 8bit and decide you want better performance, use Repetier or Sailfish instead of Marlin, they are much more optimized so the slow processor doesn’t bog you down as much.
@Ryan_Carlyle , running a GLCD, Probe autoleveling, and deltakinematics is too much for an 8 bit mostly because of clock speed rather than being 32bit. An 8 bit could do it…if an 8 bit also ran at 100mhz. I don’t know of any unique features of a 32 bit processor that allow us to do things that an 8 bit couldn’t also do, short of 32 bit processors running at higher clock rates.
@ThantiK you’d need a gigahertz range 8bit processor to match a 120mhz 32bit processor. The number of clock cycles per math operation is drastically different between the two. 8 bits is never enough precision for 3D printing calculations, so many math ops are 16+ bits. That requires carry and memory shuffling for the 8bit processor, often hundreds of clock cycles depending on the math op, but can be done in one or only a few clock cycles by the 32bit processor.
Thank you all for your input. I think I will be going down the RADDS + Due path… I like having the option to choose the drivers and go to more “exotic” ones like RAPS128 or TMC2100…
@Romeo_Pavel I love SD6128s (same chip as RAPS128 but better carrier board design) in RADDS/Due. Works great. People are having trouble finding RADDS boards right now though. If you’re willing to hold off a bit, DuetNG looks really promising. It won’t be for sale for at least a few more months though.
@Ryan_Carlyle , if that were true, the higher clocked Raspberry Pi 3 would be a speed demon at 64 bits vs 32 bits. That’s just not the case. It’s marginally better at best. About exactly equal to the clock rate increase.
While 32 bit processors may be less restrained on resources, being 32 bit doesn’t automatically make them faster at processing data, clock rate does. Less restrained resources also means being able to access more data at a time, which we weren’t all that constrained with.
@ThantiK Depends on what kind of math you’re doing. If you have to do a lot of 16x16=32 bit multiplies, a 32bit and 64bit processor will each require exactly one clock cycle per multiply while an 8 bit AVR needs 100-200 cycles depending on how you optimize it. So for that kind of math, the 32bit MCU is an enormous performance boost over 8bit whereas there’s zero marginal speed gain for the 64bit processor after that. As it happens, 32 bits is more than enough precision for most math that most code wants to do. So you mostly see 64bit adding more value when you need large amounts of addressable RAM or very complex calculations / very large fixed-point numbers. Since most of our 3d printers are still running GRBL ports on largely 16bit math ops without any optimization even for 32bit execution, there’s no chance in hell that you’ll get any bang-for-buck out of the 32->64 jump. The code isn’t set up to take advantage of it. And it’s not obvious if there’s even much POTENTIAL use for 64bit math in this application. (I wouldn’t know.)
The MCU also doesn’t spend all that much of its time on multiplication in a 32bit controller, unlike in an AVR which is completely bogged down with basic math ops to run the steppers and acceleration, so making math ops even faster is obviously going to deliver diminishing returns compared to the huge 8->32bit jump.
There’s also a question of whether your MCU has a floating point unit (eg Cortex M4 in DuetNG over the M3 in Smoothie and Due). That’s a decent speed boost to execution of kinematics calculations and autolevel rotation transforms and the like, because you can cut the clock cycles per FP multiply by maybe a factor of ten.
Also the Raspberry Pi 3 although a 64 bit chip only has a 32 bit version of Raspbian available so it never runs in 64 bit mode. I believe this is because it there are no 64 bit versions of its proprietary boot loader and graphics drivers.
@Ryan_Carlyle , that’s one of the things that I was disappointed about on the smoothie LPC1769; no FPU. 
@ThantiK Yeah, I don’t really know why everybody opted for Cortex M3s initially. The M4(F) is much better suited to 3d printer control. I guess it was too new (2010) at the time people were making all the first-gen 32bit boards. And now that people are making second-gen 32bit boards, they’re going for M4s instead of M7s. The M7 can do two instructions per clock cycle and runs at about twice the clock speed as the M4. Oh well.
The usual reasons : cost and availability. M4F is great value for money right now as the M7 occupies the high end. If money was no object, then there are dozens of faster processors to choose from … https://developer.mbed.org/platforms/Renesas-GR-PEACH/
@bob_cousins Nicest thing about the M7 that I can see is code compatibility with M3/M4F firmware. I’m not an expert at this, but as far as I can tell, once Smoothieware and RepRapFirmware are working on M4Fs, it should be trivial to run them on M7s. Early adopters who will be buying Smoothieboard v2 and Duet WiFi before Chinese knock-offs appear aren’t all that price-sensitive, I don’t think.
The firmwares for Cortex A chips all seem to be software-on-RTOS architecture (which I’m strongly supportive of in the long run), but the fast bare-metal firmware on Cortex M class chips is still competitive for now. It’s a good bridging solution to use the existing mature codebases while the RT Linux options like Redeem mature.
@bob_cousins And yes, my views on this are constantly evolving, in no small part because of your comments on the subject 