For almost the last decade, desktop 3D printing has, at its heart, been centered around 8-bit microcontrollers. The ATmegas and other Atmel chips are good enough to move a few steppers and squirt some plastic. With faster processors, you get smoother acceleration, leading to better prints. Modern ARM devices have a lot of peripherals, allowing for onboard WiFi and Ethernet connectivity. The future is 32-bit print controllers.
Right now there are a few 32-bit controllers, from the very weird, out-of-nowhere controller for the Monoprice Mini 3D printer to the more traditional SmoothieBoard. Only one of these boards has the open hardware cred for a proper 3D printer controller, and a this year’s Maker Faire, Cohesion3D introduced a few machine control boards built on top of Smoothie that add a few interesting features and techniques.
There were two or three offerings from Cohesion3D, depending on how you want to look at it. The star of the booth was obviously the Cohesion3D ReMix – the big board with six sockets for Pololu motor drivers, an LPC17xx microcontroller, a 20 A MOSFET for a big heated bed, protected endstop inputs, WiFi provided by an ESP8266, and a space for an Ethernet module.
The next-smallest board presented is the Cohesion3D Mini. This board really isn’t meant for 3D printers, although since there are four motor drivers it’s certainly possible to build a printer with it. The Mini is designed for small desktop mills and laser cutters. Right on the board is a connector for a K40 laser cutter, that ubiquitous Chinese laser cutter that always has a terrible control board. With a small, inexpensive adapter that plugs right into the endstop pins, the Mini is a drop-in replacement for the K40’s control board. Like all boards running the Smoothie firmware, upgrading the firmware is as simple as plugging the board into a computer, dropping a text file on a drive, and resetting the board.
While not officially a Cohesion3D product, there was a third board presented at Maker Faire. This unnamed but very tiny board is basically a Smoothie system on module. It features the LPC17xx microcontroller, a USB receptacle, microSD socket, reset button, and a bunch of castellated pins. These pins are intended to be connected to stepper motor drivers, GPIO, endstops, MOSFETs, and everything else a CNC or 3D printer control board needs. It’s a pretty smart little device, and while I don’t know if it’s going to be released, it does signal the coming commodification of 3D printer paraphernalia.
In looking at these boards designed for the Smoothie firmware, it’s hard not to draw parallels between the two or three most commonly used 3D printer firmwares, and the vast ecosystem of ATmega-based 3D printer controller boards. There are dozens, if not hundreds, of printer controller boards, all designed for a different task. The RAMPS is almost a standard in itself, but if you need a 24V board, you might want to give the RUMBA a look. If, for some odd reason, you need six motor drivers, there’s a board for that too.
The ecosystem of 3D printer controller boards has filled every ecological niche, but only on the island of 8-bit microcontrollers. Over in the land of 32-bit microcontrollers, there aren’t really that many options. If anything, the offerings from Cohesion3D is the first generation of boards after the introduction of the Smoothieboard. There’s going to be more of these boards, and they’re all going to serve enough use cases to be viable.
The SmoothieBoard itself is coming up on version two, or so we’re told, and of course that board will have enough new features to make things very interesting. Until then, if you’re looking for a 32-bit motion control board, your options have just doubled (or tripled). It’s a great time to build your own CNC machine, and it’s only going to get better.
There’s also the Azteeg X5, the Sunbeam 2.0, and a few others. I just pointed you at my direct competitors, welcome to the Open-Hardware family :)
https://plus.google.com/u/0/108707975258053857780/posts/QHY1J69tKub
Like I said, big day for Smoothie.
I’d never heard of the Sunbeam. I was only aware of the MKS SBase one.
If the Arduino Due didn’t totally suck (closed source, 3.3V only, price was too high, etc), it would have had a lot of potential.
The flash being separated into two banks actually means you can’t fit Smoothie in there ( too much awesome … ). Before we figured that out there was an attempt at porting Smoothie to it, and if it had fit, it’d probably be pretty popular right now.
The other issue I had with some of the Due based controllers was that different people distributing the board and derivatives did very dumb things with some of the designs. Some just threw things together and sold them touting that it interfaced with the whole Arduino playground.
I had an Ormerod 2 3d printer kit with a Duet board that didn’t contain proper terminals for powering and controlling steppers leading to a few of the connector ends to become charred/burned since they couldn’t handle the current. I had to replace the connectors with terminal blocks instead that could handle the current load. I think the big thing that bothered me about this, is that the whole Arduino bandwagon, although great causes serious problems when you have catastrophic failures like this in products riding on the coattails of the brand.
I also have a Rostock that uses the Rambo Board and haven’t had any issues (fingers crossed) since I started using it about almost two years ago.
I can understand the case to have things closed source like the Arduino brand, but I think the bigger issue is the crap derivatives that people spun off and then had huge oversight on other critical parts.
The Rambo board is really great. The Smoothieboard v2 is going to be taking quite a bit of inspiration from it, in particular the additional protections.
That’s my next to do for my Rostock. The rambo is great to keep around for another smaller iteration should I get the time to make a kossel. Either way, good work and glad to see people are making progress with the controller boards.
Try a Teensy, same chip as the Due most pins 5v tolerant and I think (not 100%) it is open hardware.
I expected the Teensy to be Open-Source too, but I just looked it up ( https://www.pjrc.com/teensy/index.html ) and I can’t find the sources anywhere, nor a mention of it being open-source …
The bootloader is closed source. Paul does enough open source contribs to libraries, so that more than makes up for it.
Not to RMS it doesn’t.
I don’t care that it is closed source, Paul offers an amazing product with A+ support, He is one of those people that really care about their product and will go the extra mile to help people should they need it.
You are not required to use the bootloader for a RMS compliant solution. Just use SWD.
There are 5V capable NXP / Freescale Kinetis processors and TI has 5V tolerance on the GPIO in the TM4C123G- it’s analogs are limited to 3v3. Not too sure what ST Micro offers in the 32 bit ARM sphere.
Damn enter / shift button confusion again…. :(
All have some support from various RTOS, if needed, and the TI TM4C123 is supported by Energia and has TI-RTOS support freely distributable, but obviously any software would need ported to support the actual hardware / MCU abilities and peripheral set.
Most of the stm32 line (all of them?) have 5v tolerant GPIO pins, so interfacing with 5V logic isn’t too hard.
If it wasn’t clear in your comment, the NXP/Freescale’s MKE series of ARM processors are natively 5V, not just 5V tolerant. It looks like none of them have USB though (someone correct me if I’m wrong).
Yeah, maybe I could have worded that better.
There are Kinetis processors that are completely 5V compliant and compatible from GPIO through ADC. But there are also some Kinetis which are not.
I have had almost 0% exposure to ST chips, hence why I said I am not sure about them. It would make sense, though, that they would have at least some which are tolerant of 5V0 on GPIO, if not ADC too.
MKE are 5v native microcontroler, Some kinetis are 5v tolerant on digital pins (see max specs in datasheet), like MK64Fxxxx (and others).
Don’t let 3.3V scare you off. I think most 32 bit uCs are 3.3V, it’s worth looking into. A good deal of 3.3V chips are 5V tolerant, like what Smoothieboard has. 5V CMOS logic generally accepts 3.3V “high” signals as “high” on 5V. I ended up taking advantage of that property in making a level shifter for external stepper drivers that require more than normal. Smoothie can operate in open collector too, for lower power optocouplers found in some external stepper drivers.
*And* you can configure pins as Open-Drain so if you really need to control something that wants a 5V input, you still can … Plenty of people do this for Smoothieboard and external stepper motor drivers.
Craftwares CraftBot runs with two 32-Bit controllers too (one in the color graphics display unit, and one main controller). They are unfortunately closed source, but i would guess that they used some existing code (smoothieware?) somewhere as a base for theyr pr3Dator-firmware…
[Brian Benchoff], I was used to better researched articles from you:
“With faster processors, you get smoother acceleration”
That’s a myth. 8-bit controllers, given a proper firmware, accelerate just as smooth as any 32-bit controller. 32-bit controllers can achieve higher stepping speeds, in case that’s needed. It’s sometimes needed on non-carthesian bots like delta printers, not so much on carthesian ones.
“if you’re looking for a 32-bit motion control board, your options have just doubled”
Straight wrong, sorry. There are the Azteeg boards, there’s Gen7-ARM, there are the AZSMZ variants, there’s the pretty popular Duet, there’s RAMPS-FD, there’s the Ultratronics, there’s RADDS, there’s the Replicape. All available already. On top of that a number of hand-wired controllers, e.g. based on the ARM STM32F411, achieving a rate of 600’000+ steps/second.
The reason why most of the RepRap universe is still stuck with 8-bit controllers is simply price: one can’t beat a $15 chinese RAMPS with a $10 chinese Arduino clone. And these boards work well enough to not make up an urgent demand for a change.
One of the best achievements of all these 32-bit controllers: they managed to break the Marlin monoculture. Whenever I see somebody cheering about 32-bit boards, declaring 8-bit ones as crap, it turns out they didn’t have an advantage from the faster computing speed, but from the easier firmware configuration and/or the better connectivity (Ethernet, WiFi) of these boards :-)
It’s no myth.
If you were to have as good step generation and acceleration as Smoothie does have, on a 8-bit microcontroller ( or a more limited M0 chip ), you’d have to step slower than normal printing speeds require. This has been pointed out to you time and time again, and you refuse to look at the facts and at the code, and just spew out the same flawed logic time and time again.
When printing, Smoothie utilizes the microcontroller’s processing time fully to get the smoothest stepping and acceleration it can out of it. This is something Smoothie does, this is something that exists in the way the code works. This notion you have that chips, with something like an order of magnitude difference in processing power, doing the same job but with drastically different means at their disposal, would result in a similar preformance/smoothness outcome, is not just ridiculous theoretically, it’s also demonstrably false if you look at how Smoothie works and how it performs.
Smoothie could easily do 500khz stepping speed ( and much more with the cheats Marlin is allowed ). The reason why it’s currently limited to 100khz is *because* it’s using that processing power difference to improve the step generation and acceleration quality.
Your argument as I understand it is “Smoothie does the same thing they all do, it just can step faster”, is that correct ? If it is your argument I’m sorry but that’s just not true.
If you ever took the time to take a honest look at the code, you’d realize you are wrong about this, but instead you prefer finding new places to repeat the same old flawed arguments …
Now I am not that familiar with stepping motors but can’t see why generating a 500kHz step frequency would be a problem for a 20MHz AVR chip? I’ve done code for 1.5Mbps data transfer with extra overheads for such chips (USB low speed).
And it’s not just 500khz step frequency that is the problem.
Say everybody gets a 10khz target, and they need to do step generation and acceleration as close as they can from the “theoretical perfect”.
The 8-bit chips are going to have a much harder time getting to perfect, than the 32-bit chips will have.
And in practice, if you compare what is actually going on, Smoothie gets much closer to that perfect … and there is a reason for that : there is 4 years worth of work that was put into making it so.
Yes, if you don’t put any effort into being better, you are not going to be better. The point is Smoothie *did* put a lot of effort into being better, and is was *able to* due to the higher processing power, where the 8-bit chips have limitations they *physically* can’t get over …
Smoothie did put a lot of efforts into making stepping more accurate, as did many others. At Teacup we measure this accuracy and find it to be accurate to the CPU clock (50 ns), evenly distributed on each individual axis: https://github.com/Traumflug/Teacup_Firmware/issues/233#issuecomment-236642201
Very apparently there are no physical limitations prohibiting one from doing this, even on 8-bit boards.
Still I currently consider the DC42 variant of RepRapFirmware to be the best firmware, because this firmware does the same for Deltas, too. No segmenting into short straight lines, every single step on every motor is calculated individually to match that geometry and the required timing.
@Traumflug : I’m glad you guys are working on improved step generation. And apparently getting good results.
Did you measure what is the fastest step rate you are able to reach with this method while still maintaining the 50ns accuracy ?
About the RRF, there were measurements of step generation that showed no difference between the segmented and segment/less approaches, because at high enough segment rates, segment length is anyway smaller than machine limitations ( microstepping etc ). Because of this, we consider the segmentless approach to essentially be needless complication of the code, for the moment ( which comes at the cost of limited max step generation rate if I remember correctly ). However, we are glad it was tried, and are very open to anyone in the future showing it has some advantage ( maybe when everybody starts using even higher microstepping or more precise linear motion ? )
Yes, we measured that. 48’000 steps/second on a 20 MHz AVR, 120’000 steps/second on a Cortex-M0, somewhere between 500’000 and 650’000 steps/second on a Cortex-M4. The latter number currently varies a bit, because one Teacup developer works on breaking the 500 kHz barrier safely, with some margin for other tasks.
Oh, and I didn’t understand your original message ( I missed a negative ).
But to answer the question “I can’t see why generating a 500khz step frequency would be a problem for a 20Mhz AVR chip”, the answer is as follows :
We are not just blinking a LED at 500khz, which would be quite easy to do. We are processing Gcode, generating a look-ahead queue, computing optimal acceleration/decelation ramps over that queue, and then generating steps and modifying speeds ( accel/decel ) for multiple axes simultaneously. All that together is much more computationally expensive than just “generating a static 500khz PWM signal” or “outputing data at 500kbps” …
… and Smoothie does it better :p
Anyone generating steps with “processing power” is doing it ludicrously wrong. That’s what independently running hardware is for – at the absolute minimum, one is supposed to rely on hardware timers to generate timing, not on CPU cycles, which makes them moot past the point where you have enough of them left to service events; 8-bit MCU with strictly deterministic timing actually have the upper hand here over ARM CPUs with unpredictable bus arbitration and such. The proper way though is using hardware timers with hardware pin toggling on compare match, at which point the only thing of interest (past your timer clock which is indeed always the more the better) as far as the CPU is concerned is being able to prepare a new pulse value somewhere between the last and the next – when exactly you get to do it is utterly irrelevant to precision as long as you get to do it in time. Oh, and regarding that fabled development time you’re so spectacularly proud of – the only guarantee is that in too little time no result can be achieved, the opposite means precisely zilch. Time squandered on something is by no means a measure of progress. It’s perfectly possible to spend not years but decades and not only not make any progress but actually end up with an inferior product than what you used to have – just ask Microsoft.
@Max : That’s all well and good, but if you had any idea what the code actually does you wouldn’t be saying any of this …
We do use timers, we use them in a smarter way, and we do more in those interrupts.
As @Traumflug himself mentioned, having interrupts is not enough, you are limited by how much you can do within those interrupts. Imagine you would be able to add, but wouldn’t have enough time to check if the move is complete or not : you wouldn’t even be able to actually do step generation then. From there, you can use more and more *time* to do step generation better and better. Smoothie has more time, and has code to *use* that time to best effect.
Go grab your logic analyzer, flash a smoothie with a 4-year old firmware, and compare it to the current firmware. And then compare that to what Marlin, or Teacup can do. Or read the code.
There are *many* possible ways of doing step generations, and many have actually been implemented. Some implementations are better than others, is my point here. And result in demonstrably better ( closer to a theoretical perfect ) step generation.
The work I mention was put into trying different methods, figuring out which are better, and moving step by step to better and better ways of doing this.
Your argument of “just because you spent time doesn’t mean it’s better” is pretty moot : my argument isn’t that time was spent, my argument is : go read the damn code, and if you do so it’ll be obvious to you what’s better than what here. I mention time spent on the code for people who don’t have time to actually go read it.
I’m not “spectacularly proud of” our step generation code, I’m saying we spent a lot of effort on actually making it better, with success. Others might have chosen to spend their efforts on other things, we spent time on that ( with results ), therefore it is relevant to this conversation … I’m not sure what’s hard to understand here.
Just out of curiosity, based on what people are saying in this discussion I would think that a multi-core processor would be ideal for this application. Is there something inherently wrong with this way of doing it?
We are actually going to be trying that with the Smoothieboard v2 hardware, which uses a chip that has a M0 co-processor, which will be used just for step generation and nothing else.
So the version 2 is going to be kind of like a Beagle Bone Black that has one of its PRUs doing all the stepper pulse generation.
There are a number of reasons why that’s non-trivial:
– Stepping has to happen not at some maximum speed, but at a defined speed. Which means, one has to count the CPU clocks between two steps somehow. Usually that’s done with a timer. Setting up a timer and executing the timer interrupt costs clock cycles, of course.
– Everything but a trivial bot moves more than one axis, so these axes have to be synchronized. Popular algorithm for that is Bresenham, there are others. Some portion of that code also executes when moving only one axis, of course.
– Movements should have an end. Which means, there has to be some code to test whether the movement is completed.
– Acceleration calculations add up on top of that. They’re the most computing expensive part, but pause during the constant speed part of a movement.
Each of these parts isn’t too much, but 50 kHz on an 20 MHz AVR means only 400 clocks per step, so just testing four 32-bit values against zero ( = movement end) bites already, because that counts in at some (IIRC) 64 clocks already.
Doing something at a specific rate is most efficiently done with timed code – interrupts costs cycles.
Bresenham is trivial and shouldn’t interfere with an acceleration algorithm? I’ve never coded such control code so may be mistaken.
Checking for end of movement shouldn’t (AFAIK) interfere with the acceleration algorithm, is shouldn’t be done per step either given that it is trivial to do in an outer loop. Calculate earliest deadline and loop until that is reached. It is more complicated when each motor have a separate acceleration but not overly so.
Doing the acceleration calculation seems like something that should be fitting for table lookups, while I haven’t done much with steppers similar things have been made very clean with a few tables.
Doing this with timed code means the CPU is fully occupied during any movement, how would you process incoming G-code during that time?
Checking for movement end also means to decelerate in time to approximately reach zero speed when the movement distance is done, too.
And there is no curved movement so far (circles, beziers, polar or delta bot geometry), which can all be done while the timer is running, but only much more expensive in a timed loop.
I mean, you’re certainly invited to try on further improving these algorithms. Teacup code is said to be readable and available here: https://github.com/Traumflug/Teacup_Firmware Some movement planning considerations are written down here: https://www.reprap-diy.com/printer_controller_trajectory_planning
Are these boards fully CE compliant? From what my eyes can see on these pictures, i can’t see enough filters and protection devices. And from my experience with looking at the layouts (if the are open and available), the routing and general layouts are usually not really designed to help reduce emission and immunity either…
I doubt that any of the consumer accessible control boards are CE compliant, nor likely to be, just due to the high step rate signals going to the motors making the leads all unintentional radiators, regardless of the traces on the boards being accessible and therefor potentially noisy.
Most likely route to attempted CE emissions compliance would be to fully enclose the printer, and shield using the enclosure, as well as potentially enclosing the control board in a RF barrier container of some sort.
That said, the control boards also have to dissipate heat from the stepper drivers and the MOSFETs for the bed heater and hot end heater(s) so it would need to be ventilated as well.
Most power supplies used on 3D printers are cheap Chinese LED string supplies, though some use ATX power supplies. The noise output from the LED supplies is likely to add more interesting emissions to the printer, with potential to radiate on any of the wiring in use, depending on how well the controller filters those lines (limit switch wiring, or work illumination for example…)
More related to the 8bit vs 32bit discussion above, there is also the audio harmonic value of some of these emissions, when you consider that the steppers are being driven at 10+ KHz.
At 10KHz, this is right in the middle of the human hearing spectrum, and causes what is often called “singing steppers” when running a print job.
Some of the stepper drivers attempt to run it at much higher frequencies to get it out of the audible spectrum, among other tricks to reduce the audible noise.
I just bought a DuetWiFi controller, partially due to the stepper drivers used, and their reputation for near silent operation.
The faster step count helps as well, as I am building a new delta printer, with 0.9 degree steppers, so it will require twice as many steps to move the same distance as a 1.8 degree stepper motor equipped printer would. The finer step size, coupled with small pulleys make for better precision on the printer, but both increase the step rate requirement. Trying to pull it off at any decent movement speed is a recipe for aggravation, if attempting to do so on a 8bit controller.
And then your neighbors Netflix will go all fuzzy and a weird guy dressed like Max Headroom will break in and tell them to inform the FCC…
Sunbeam 2.0