SmoothieWare Compatible Mainboards

[thinkl33t.co.uk]

SmoothieWare Compatible Mainboards
I’m a big fan of the SmoothieWare project for driving 3D printers, CNC machines and Laser Cutters. The code is clean, efficient, and the software actually designed in a modular and sensible fashion. Compared to most 3d printer firmwares, which have accrued layers of cruft, its very readable and usable.

The only real issue is there isn’t a huge amount of hardware out there that’ll run the firmware. This post is a compilation of the available boards as of January 2015, and my thoughts on each. Prices will be in GBP, using Google’s conversion rate, and include the cheapest shipping rate to the UK. I’ll only be counting items that are in stock and ready to order right now, not pre-order items. If there are multiple options for connectors etc, i’ll choose the cheapest.

SmoothieBoard
SmoothieBoard
Photo from [smoothieware.org]
Available from RobotSeed for £108 (€142) inc shipping for SmoothieBoard 5X, the SmoothieBoard is the big daddy of them all. It has 5 onboard A4982 stepper drivers with digital current control, 6 endstop connectors, 4 thermistor inputs and 6 MOSFET outputs, which can drive 3 high current (hotend, heated bed) and 3 medium current (fans, lights, relay) devices.

The SmoothieBoard benefits from being the primary development platform for the SmoothieWare project, so will probably never become unsupported, and has a huge amount of IO, which means it’ll be able to support pretty much any stepper-based machine you want to throw at it. The SmoothieBoard has the stepper drivers mounted directly on the mainboard, which is far better than pololu-style stepper drivers as favoured in the reprap world from a thermal point of view.

The SmoothieBoard supports ethernet networking, which is very nice functionally. SmoothieWare supports gcode streaming over TCP, and has a rudimentary WebUI.

The downside is it is a bit expensive for running things like CNC machines, as you end up paying for a lot of features you wont use, and it is on the large side, which makes it not ideal for small delta machines. There is provision for attaching external LCD controllers, the RepRapDiscount GLCD is the recommended unit, however it does need an additional adaptor PCB for truly plug-and-play assembly.

Price 7/10 (a bit expensive, but well featured)

Features 9.5/10 (some features need extra bits attaching, like the LCD adaptor PCB and 5V regulator).

Azteeg X5 Mini
X5
Photo from [www.tridprinting.com]


The X5 Mini is available from panucatt for £80 ($122) inc shipping. It is a 3D printer focused board, featuring 1 High Current MOSFET and 2 medium current MOSFETs. It boasts 4 onboard stepper drivers, this time DRV8825 types, which have 32x microstepping and can drive up to 2.5A stepper motors. Input wise, it has connectors for 4 endstops, and has 2 thermistor inputs.

The X5 is significantly smaller than the smoothieboard, which will help with mounting. For those of us coming from old-school reprap electronics, it is close in size to a sanguinololu. Again, the RRD GLCD can be attached. No PCB adaptors are available that I can find, but making up an adaptor cable is fairly simple. There is no onboard networking provision.

Price: 7/10 (£20 cheaper than the smoothieboard, but you get a lot less for the saving)

Features: 6/10 (Only 1 Extruder, No network, LCD needs cable making)

AZSMZ Mini
AZSMZ
Photo from [www.aliexpress.com]


The new kid on the block, the AZSMZ Mini comes in at an astoundingly cheap £46 from AliExpress. This increases to about £60 when you include 5 DRV8266 based stepper drivers.

Assuming we ignore the incomprehensible name for now, it has some interesting features. The size is slightly bigger than the X5 mini.

It is the only SmoothieWare compatible board for sale right now that has removable stepper drivers, which a lot of people seem to like. While this gives you the choice of which stepper drivers to use, it also means you’re limited on how much heat you can remove from the driver, decreasing your total motor current. It has 5 slots for stepper drivers, using the standard pololu-style pinout. As Pololu carriers are in use, there is no digital current control on this board.

There are 3 MOSFET outputs total, 1 High Current, and 2 Medium Current, Labelled Bed, Fan and Heat, along with 3 Thermistor inputs, allowing for dual extrusion. I would have liked 1 more medium current output, as assuming you want to use dual extrusion, you can’t have a fan without adding an external MOSFET board. Provision is made for 4 endstops, labelled X, Y Z and A.

Like the X5 Mini, there is no networking provision on the AZSMZ.

This board has a dedicated GLCD controller available, also from AliExpress for £19. This LCD connects directly to the EXT2 and EXT3 ports, meaning connecting it is zero hassle. Though it uses the same connectors, these controllers arent the same as the ones on the RRD GLCD, so if you really want a RRD you’ll have to make an adaptor.

As it is so new, a certain level of wariness may be good to adopt when it comes to the AZSMZ. As far as i’m aware, nobody outside of china has them in-hand yet, and the reliability is yet to be tested. From an EMI perspective, the position of the USB connector is a bit suspect, as the USB lines appear to pass through all the sources of noise on the entire board, Extruder PWM, Stepper Drivers and switching VReg!

Price: 9/10 (Though its yet to be seen if its cheap for a reason, and you need to include the cost of your stepper drivers!)

Features: 7/10 (The extra extruder and onboard LCD provision put it above the X5 mini, but the limited number of high current outputs is strange for a supposed dual-extrusion board, and the lack of digital current control is a pity)

Sunbeam 2.0
Photo from [3d-printers.pl]
Photo from [3d-printers.pl]
The Sunbeam 2.0 costs £101 (PLN 570) from 3d-printers.pl shipped to the UK (assuming i’ve translated the website correctly!). It is another general usage board, similar in concept to the SmoothieBoard, but with a few changes.

For external connection, there are two USB ports onboard, a native USB, and a “Debug” FTDI chip. The debug port can be used for direct access to the microcontroller’s serial port, including for flashing bootloaders etc. The Sunbeam also has Ethernet onboard, allowing the WebUI and Network Streaming to be used.

The stepper drivers change from the A4982 to the A4988. The main difference is that the A4988 supports 8x microstepping, and the A4982 is in a slightly bigger package, so is theoretically easier to swap out if you do blow a driver up. There are still 5 motors, allowing dual extrusion on a 3D printer, and there are still 3 High current outputs (Bed, E1, E2), and 3 Medium current outputs (labelled as Fan outputs).

Input wise, there are only 3 Thermistor inputs, and 3 Endstop inputs. This is pretty much the minimum to run a dual extrusion 3D printer, I would have liked to have seen at least one more endstop input for bed probing. An onboard switching regulator provides 5V for general power from the 12-24V supply power.

Like the AZSMZ, the Sunbeam has a connector intended for connecting a GLCD. This addon is available from 3d-printers.pl for £32 (PLN 179.99) including shipping, and plugs into a single ribbon connector on the board.

The only real issue I have personally with the sunbeam 2.0 is that the documentation is only available in polish, though connector pinouts etc are all labelled in English so connecting things up without the documentation should be no problem.

Price: 8/10 (Around the same price as the SmoothieBoard but you dont need to buy any adaptors or regulators for full functionality.)

Features: 10/10 (About as feature complete as you can get!)

Conclusion
I know these things usually end with a conclusion that tells you which board to buy, but with this subject depends hugely on what machine you’re building, and the features you want and need.

Personally, I’d get a sunbeam 2.0 for any project where it’d fit physically and fiscally, and drop to the AZSMZ where budget or space disallows.

how about supporting the original designers and just buy a smoothieboard.

In my view you shouldnt buy the clone boards that provide zero support to the orriginal smoothieboard designers.

Thank you for the summary! I've been meaning to write one myself.....

I love you cxandy. You have added a post in a right time because my old board burned and i'm going to get another one. Thank you soooooooooo much

Quote
cxandy
AZSMZ Mini
AZSMZ

If you contact them, please also ask them to publish their sources. Just had to tag it as NotOpenSource.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
cxandy
AZSMZ Mini
AZSMZ

If you contact them, please also ask them to publish their sources. Just had to tag it as NotOpenSource.

What exactly do you need? (I know zilch about OSH requirements.) The Eagle files are available in github:

https://github.com/Rose-Fish/AZSMZ-mini

https://groups.google.com/d/msg/deltabot/5OHu1uIhSy4/paOrmZtALHAJ

Arthur Wolf and the Smoothie folks have been working with them to get the board properly documented as open-source and compliant with all of the Smoothie obligations.....

@vreihen

the board files are missing. Just the schematic is not enough to be open source!!!

Quote
vreihen
I know zilch about OSH requirements.

600+ posts in this forum and then this? You're kidding, aren't you? Think of what you'd need to make an identical copy or a slightly modified copy. That's what's required.

That said, glad to see so many other 32-bit boards. kthx on IRC currently counts 10 such designs. The only really adorable thing about Smoothie is its marketing. Arthur got that really right. Just saw a review video of Thomas Sandlander and had to watch how he cheers on how you "just edit a text file for configuration" and praises it as revolutionary and new. In fact it's the exactly same thing we always did. We edited configuration.h and hit the upload button.

Same for stepper drivers: works fine, but nothing new. And then you look into the comments section of that video and he answers many comment with just "Smoothie. It's the future". Like a broken record. Clear indication that marketing got it entirely right.

Now let's go into the real future and create a $50 board featuring all this, except the broken record. Easily doable and 9 times already done.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
vreihen
I know zilch about OSH requirements.

600+ posts in this forum and then this? You're kidding, aren't you? Think of what you'd need to make an identical copy or a slightly modified copy. That's what's required.

No, I'm not kidding. I have no interest for going into the board design/manufacturing business, and do not know anything about the hardware licensing side of open-source. (Honestly, the software side of open-source makes me want to pull my hair out with all of the different licenses out there.)

Anyway, from the thread on the Google Deltabot group, I have seen that Arthur Wolf has been in touch with the developers of the AZSMZ Mini to bring them into compliance with Smoothie's requirements. He even had the re-label the schematics and change the silkscreen on the boards that referenced the board using a derivative of the Smoothie name. I have not followed up to see if they jumped through every hoop, but making the board open-source is their published intentions per the Deltabot forum thread.....

Quote
vreihen
Honestly, the software side of open-source makes me want to pull my hair out with all of the different licenses out there.

That's why we currently pretty much ignore licenses by handling them all equally. They aren't enforcable anyways. "Sources sufficient to make a copy" is simple enough to be understood by everybody.

Still I can't get rid of the impression that chinese vendors simply don't grok what's all this open source fuzz about and recognize RepRap as sort of a sales channel similar to Alibaba, eBay or whatever. It looks like they simply can't understand people have other things in mind than just buying. Like understanding a design, learning from it, adjusting it for personal needs. Not sure about how to show them the beauty of DIYing, making and collaboration.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

"A wise man knows that confidentiality equals profit." - The Ferengi 30th Rule of Acquisition

"Even if it's free, you can always buy it cheaper." - The Ferengi 11th Rule of Acquisition

"Sometimes what you get free cost entirely too much." - The Ferengi 218th Rule of Acquisition

This "new" Smoothieware-compatible board popped up in the Google Deltabot group over the weekend:

http://itcorp24.cart.fc2.com/ca8/48/p-r8-s/

Momoinololu M3[Rev 1.0]

I know that cxandy knows about it, and am hoping that he is writing a summary of its features to go with the list at the top of this thread.....

Here's yet another Smoothie-compatible board that someone posted in the Deltabot forum:

http://hackaday.io/project/833-3dpcb-smoothieboard-compatible-driver-pcb

Looks like it may be a dead project judging by the way the author has not updated the files since last April, but it is another option (and yes the board files are there).....

Quote
Traumflug
That said, glad to see so many other 32-bit boards. kthx on IRC currently counts 10 such designs. The only really adorable thing about Smoothie is its marketing. Arthur got that really right. Just saw a review video of Thomas Sandlander and had to watch how he cheers on how you "just edit a text file for configuration" and praises it as revolutionary and new. In fact it's the exactly same thing we always did. We edited configuration.h and hit the upload button.

I'm annoyed at people talking authoritively about the Smoothie system when the seem to have not studied it much. How about I lend you a Smoothieboard, you actually use it in a machine, and then I'll accept whatever your opinion of it is.

It's not just Thomas Saladerer, many Smoothie users will tell you they find the configuration system much more user friendly. If you never heard somebody tell you that having to open the arduino IDE to affect changes is something offputting about Reprap, you are completely disconnected from what typical newcomers experience.

You don't care, you are a power user, having to open the arduino ide and edit source files is not a problem to you, ok, that's fine. But many people do care.

Quote
Traumflug
Same for stepper drivers: works fine, but nothing new.

Again, please don't talk about a project if you haven't actually studied it on even a basic level, which is what I take away from your comments about it. Either that, or we do a very very bad job at actually showing it's features ( but you praise our marketting skills so much that's probably not it ).

Smoothie generates a smoother step pulse, does more precise acceleration, does longer look-ahead, has much better delta support, fixes issues that 8-bit firmwares do not or can not fix. The stepper drivers on the Smoothieboard can handle more current/heat than pololus, are easier to tune, and harder to break.

Yes, 8-bit firmwares work. Implying it can't be done better would be dumb. And Smoothie does it better. Read the source, or listen to it's users, or even try it yourself ( I'll lend you the board ).

Implying like you do, that the only thing Smoothie has going for it is it's marketting, is just completely ignoring it's actual design/features, and what it's users experience.

Edited 2 time(s). Last edit at 02/03/2015 07:06AM by arthurwolf.

Worth pointing out that it's not just the Smoothie that has more user-friendly configuration, better step pulse timing, more precise acceleration etc. because RepRapFirmware on Duet electronics does all that too. AFAIK it's also the only firmware that calculates the step pulse times on a delta properly. All other firmwares that I know of (including Marlin and Smoothie) chop up moves into short segments, and then assume that a short linear move can be approximated by linear moves of the motors.

The only remaining reason to use 8-bit electronics and firmware is if you are working on a very tight budget. But 32-bit processors are inexpensive now, so the price of 32-bit boards should fall.

Edited 1 time(s). Last edit at 02/04/2015 07:59AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Worth pointing out that it's not just the Smoothie that has more user-friendly configuration, better step pulse timing, more precise acceleration etc. because RepRapFirmware on Duet electronics does all that too.

I hear your web interface is very nice too. Do you have screenshots of it somewhere ?

Quote
dc42
AFAIK it's also the only firmware that calculates the step pulse times on a delta properly.

We actually want to try to implement that ( we are currently moving towards per-step acceleration, per-step IK is next on the list ).
I'm a bit lost in your project's structure, could you point to me where you do that in your code ?

Quote
arthurwolf
I hear your web interface is very nice too. Do you have screenshots of it somewhere ?

There is a screen shot of one of the pages in my blog entry at [miscsolutions.wordpress.com] about half way down (click on the image to get ot full size). I didn't write it, but I did add the dual-head support. The Print page displays a graph of progress, gives estimated end times, and allows the speed and extrusion factors to be adjusted. Another Ormerod user (zombiepantslol) is doing an updated web interface that should be more suited to small screens on tablets and smartphones.

Quote
arthurwolf

Quote
dc42
AFAIK it's also the only firmware that calculates the step pulse times on a delta properly.

We actually want to try to implement that ( we are currently moving towards per-step acceleration, per-step IK is next on the list ).
I'm a bit lost in your project's structure, could you point to me where you do that in your code ?

Gcodes for processing are fed to the Move class. The Move class fills in a DDA record for each new move by calling the Init function, does lookahead to adjust moves already in the queue as needed, and adds it to the queue. When a DDA record is getting close to being executed, Move calls Prepare on it, which freezes it (i.e. no more lookahead adjustment) and computes some parameters that will be needed by the ISR. Each DDA record has a DriveMovement struct for each possible drive, which stores the parameters for the way that drive needs to move. The actual per-step acceleration and precise delta movement are computed in CalcNextStepTime.

btw the overall architecture is not of my design, it's what RepRapPro wrote - although I have rewritten most of Move and DDA, and I wrote all of DriveMovement.

There is code for extruder elasticity compensation in CalcNextStepTime for extruders. This adjusts the extruder steps by an amount proportional to the extrusion speed, to try to compensate for the springiness of the filament in the Bowden tube and therefore avoid the classic over-extrusion at corners and hairpins, where the head slows down and speeds up again. But on the Ormerod at least, it doesn't work as well as I had hoped. So I may remove it. Someone else suggested just advancing the extruder movement a little compared to the axes. I could do that if I separate the DriveMovement structs from the DDA, so that movements for more than one move can be active concurrently.

btw ignore the 'delta' branch in my repository, that's old code now. My 'dev' branch is where delta (and all other development) happens now.

Edited 1 time(s). Last edit at 02/03/2015 01:14PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
arthurwolf
I'm annoyed at people talking authoritively about the Smoothie system when the seem to have not studied it much.

I'm annoyed by people claiming I did not study what I'm talking about. Smoothieboard schematics are right here on my PC, next to about 15 other designs.

Quote
arthurwolf
If you never heard somebody tell you that having to open the arduino IDE to affect changes is something offputting about Reprap, you are completely disconnected from what typical newcomers experience.

We're getting closer. It's not the board, it's the software. GUI configurators are now about everywhere. It's simply the logical next step to implement them, if just to reduce all the helpless questions coming from newbies.

Quote
arthurwolf
Smoothie generates a smoother step pulse, does more precise acceleration, does longer look-ahead, has much better delta support, fixes issues that 8-bit firmwares do not or can not fix.

Smoother than what? More precise that what? Better than what? And again, all these are properties of firmware, open to any board.

Quote
dc42
AFAIK it's also the only firmware that calculates the step pulse times on a delta properly. All other firmwares that I know of (including Marlin and Smoothie) chop up moves into shoit segments

Oh, you managed to move non-straight (in terms of motor movements), still step-accurate lines? That's indeed something worth looking at.

Quote
dc42
The only remaining reason to use 8-bit electronics and firmware is if you are working on a very tight budget. But 32-bit processors are inexpensive now, so the price of 32-bit boards should fall.

That's certainly true. Nevertheless, there's also no reason to get a 200 hp engine (32-bit CPU) when you're always constrained to drive within city limits (e.g. simple carthesian printers, CNC milling machines). 8-bit CPUs are simply fast enough for many applications, no need to throw them away. Some two months ago a Teacup firmware user got his printer running with an € 3.- Arduino Nano. Cheers to that!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
arthurwolf
Smoothie generates a smoother step pulse, does more precise acceleration, does longer look-ahead, has much better delta support, fixes issues that 8-bit firmwares do not or can not fix.

Smoother than what? More precise that what? Better than what? And again, all these are properties of firmware, open to any board.

It was implied : "than 8-bit boards running the current 8-bit firmwares".

I absolutely do not see how those are open to any board. They might be "open" to any 32bit board, but that doesn't mean they all implement those ameliorations in their respective firmwares.

For example the most basic of Smoothie's ameliorations, using a base stepping frequency for step generation, is pretty much impossible on an 8-bit board without completely sacrificing the step rate. And that's true for many other such ameliorations.

Do you deny that the current 8-bit firmwares are pretty close to having reached the limits of what can be implemented on 8-bit boards ? Because last time I asked, even major 8-bit firmware devs did not deny it ...

When using your panel actually slows down the machine's movements, you know there's a lack of room somewhere ...

I'm sorry but when you imply that the -only- thing Smoothie has going for it is it's marketting, I can't help but feel you are being dishonest in some way. Either that or I did not undersand what you meant.

Edited 2 time(s). Last edit at 02/04/2015 08:05AM by arthurwolf.

The 32-bit boards have other advantages too, such as software control of motor currents, built-in web interface, and high speed uploading to the SD card (via HTTP or FTP in the case of the Duet). You could do digital control of motor currents with an 8-bit solution, but not the other two. I know there are add-on solutions for controlling 8-bit printer electronics from a web interface, but a web server that controls the printer over USB using gcodes can't compete with having a direct HTTP interface into the printer firmware, which is free from the serial gcode interface and so can provide printer status in real time.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
The 32-bit boards have other advantages too, such as software control of motor currents, built-in web interface, and high speed uploading to the SD card (via HTTP or FTP in the case of the Duet). You could do digital control of motor currents with an 8-bit solution,

I think the RAMBO implements this.

Quote
dc42
but not the other two.

There are many other things 32bits boards can do that 8bit boards can not ( or should not ) do : time-based acceleration ( working on it in smoothie, you seem to have it in reprap-firmware ), per-step IK ( which reprap-firmware does ), module-based config ( unlimited extruders, unlimited switches etc ), showing the sd card to the computer as mass-storage ( while at the same time doing serial ), per-step acceleration, linuxcnc-like planning, and many many others, including many we have not thought of yet.

To me saying the 8-bit firmwares/board are good enough, is the reprap equivalent of «640K ought to be enough for anybody».

Sure, 640K is a lot, and you can do a lot in 640K, we all agree.

@Traumflug: You should really try the 32 bits. You might even be able to come up with a better version of your 8bit Firmware.

And they are also available in Packages you like ;-)

Cortex-M in DIP

Quote
arthurwolf

Quote
Traumflug
Smoother than what? More precise that what? Better than what? And again, all these are properties of firmware, open to any board.

It was implied : "than 8-bit boards running the current 8-bit firmwares".

In this case, all of these claims are wrong.

Quote
arthurwolf
I absolutely do not see how those are open to any board.

I'm very sorry for your shortsightedness. CPUs are digital units and all of the produce the exact same results, no matter how many bits in parallel they process. They just vary in speed. Just like 32-bit desktop CPUs produce the exactly same result as 64-bit counterparts, just a bit slower.

Quote
arthurwolf
I can't help but feel you are being dishonest in some way.

Each time your argumentations are exhausted you start attacking me personally and accuse me to lie. Thank you for that, it just confirms my logical descriptions are right.

Quote
JustAnotherOne
@Traumflug: You should really try the 32 bits

Guess what: I did already. And it works exactly the same way as on an 8-bit counterpart. Zero surprise, because both are digital computers and they calculate exactly what they're told to.

It's all a matter of a proper firmware. If Marlin and Repetier declare shaky movements and step losses as state of the art and people cheer on that, I can't help. This is a solvable problem. Not solvable by faster CPUs, but solvable with more carefully written firmwares. A fast CPU just makes it a bit simpler to do so.

Perhaps some of you remember earlier high-end CNC machinery. Many of them had a 3 MHz 8-bit CPU and they worked just fine.

OK, I'm back on hacking a properly working firmware, which works smoother, more precise and better by @arthurwolf's definition. On 8-bit, on 32-bit and on 64-bit hardware.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Edit : just to save some time and prevent Traumflug from further attempted word play : in this message when I refer to "32bits microcontrollers", you can simply replace that by "more powerful microcontrollers in general". Because yes Traumflug, a 1 GHz 8-bit microcontroller, is -not- less powerfull than a 1KHz 32-bit microcontroller, you are absolutely correct.

Quote
Traumflug

Quote
arthurwolf

Quote
Traumflug
Smoother than what? More precise that what? Better than what? And again, all these are properties of firmware, open to any board.

It was implied : "than 8-bit boards running the current 8-bit firmwares".

In this case, all of these claims are wrong.

What is this I don't even ...

So are you saying a firmware designed for an 8-bit mcu, running on an 8-bit/16-20mhz mcu, will be as smooth in it's step generation and as precise in it's motion planning and execution, as a firmware designed for a 32-bit mcu, running on a 32-bit/120mhz mcu ?
I'm not even sure I understand what you are saying.
A shitton of work has gone into getting the Smoothie firmware to take advantage of the more powerful chip. Most of that work doesn't exist or would make sense on the current 8-bit boards/firmwares, and none of them can claim equivalent befenits ....

Quote
Traumflug

Quote
arthurwolf
I absolutely do not see how those are open to any board.

I'm very sorry for your shortsightedness. CPUs are digital units and all of the produce the exact same results, no matter how many bits in parallel they process. They just vary in speed. Just like 32-bit desktop CPUs produce the exactly same result as 64-bit counterparts, just a bit slower.

So your rebutal to me saying that 8-bit electronics running at 16Mhz are less powerful than 32-bit electronics running at 120Mhz, is to actually agree that they are slower, but that's ok because it's "just a bit" slower ?
There is a very very significant difference in the amount of computing power each solution is capable of, and the Smoothie firmware does take advantage of that difference to -in fact- make things smoother, more precise, and better. I'm sorry, that's a fact, and by saying the contrary you are just being factually wrong.

I am really sorry, but if your argument all along has been that 8-bit mcus and 32-bit mcus are still MCUs and therefore there is no difference in what each makes possible, because they both are just information processing units and what matters is what is being executed on them, you wasted my time, you are way too obtuse to be talked to, and I'm pretty much done with this conversation.

There are way too many reasonable persons to talk to to waste time with this ... well I guess untit next time you spread misinformation and I have to jump in again ...

Quote
Traumflug

Quote
arthurwolf
I can't help but feel you are being dishonest in some way.

Each time your argumentations are exhausted you start attacking me personally and accuse me to lie. Thank you for that, it just confirms my logical descriptions are right.

My argumentations are absolutely not exhausted, I do think you are being either dishonest or wrong, and I actually think I can prove you are one of those.

I don't attack you personally ( you may well be a very nice person, that is very very wrong, which is why I specified I "feel" you are being dishonest, because I also "feel" you know to much about this to only be wrong ), I attack your arguments, which I think are dishonest ( or insanely mis-informed ).

But either you do not know what you are talking about, or you are being dishonest about this, yes.

Quote
Traumflug

Quote
JustAnotherOne
@Traumflug: You should really try the 32 bits

Guess what: I did already. And it works exactly the same way as on an 8-bit counterpart.

What exactly did you try ?

Because I think he implied "try what has actually been implemented and worked very very hard one for several years on 32bits chips ( ie Smoothie or the few others )" ( correct me if I'm wrong ), and if that's what he was saying, and you tried them, and you think they work exactly the same, you didn't try very hard ...

Quote
Traumflug

It's all a matter of a proper firmware. If Marlin and Repetier declare shaky movements and step losses as state of the art and people cheer on that, I can't help. This is a solvable problem. Not solvable by faster CPUs, but solvable with more carefully written firmwares. A fast CPU just makes it a bit simpler to do so.

Here you are isolating one problem that -can- be fixed on 8bit firmwares and ignoring many other things that -can- be made better on current 32bits systems, and can not be made better on current 8bits systems ( without sacrificing other things ). Which I feel is not an honest way of adressing the issue.

Actually, a faster MCU does not -only- make it simpler to do so, you are factually wrong here. If we had to implement every amelioration we made to the Smoothie firmware, every bug fix, ever special case, fine tuning, better math, all that, on an 8bit chip, it would have to generate steps at an insanely slow rate, and do very very short look-ahead. If you implement them on an 8bit system, you loose a lot. If you implement them on a 32bit system, you do not
So no, there are things that 32 bits microcontrollers do not -just- make simpler. They are made possible.

Just to give an idea. When I started coding Smoothie, it was based on a very similar ( grbl ) firmware as Marlin. Without many optimizations, I was able to push it to 450khz step generation on a 96Mhz 32bit chip. That's to be compared to the 40khz maximum step rate in Marlin ( and the steps are not very clean at that rate, it's using a hack ).
Now here's my point : nowadays, Smoothie's maximum step rate is 100khz, 4.5x times less than it was in the beginning. Where has all of this processing power gone ??? It has gone to making Smoothie " Smoother [...] More precise [...] Better ", that's where it's gone.
And just to do some stupid math, imagining we ported Smoothie to an 8-bit mcu ( well let's say we changed Marlin to do things more like Smoothie ), seeing we had a 4.5 times decrease in max step rate by implementing all those ameliorations, we can estimate Marlin's max step rate would fall by something similar, so 40khz/4.5, it'd have to run at something like 9khz max step rate to reap the benefits.
Smoothie is NOT "hey I just ported marlin to 32bits then went have a beer and never worked on it again", which you seem to think it is.

So no, you can't do -everything- on an 8bit chips, it is NOT just a matter of being great at coding, or you'd be able to run minecraft on C64, just by using your coder magic powers.

Quote
Traumflug
Perhaps some of you remember earlier high-end CNC machinery. Many of them had a 3 MHz 8-bit CPU and they worked just fine.
.

And that's exactly the reason why high-end CNC machinery today still uses 3Mhz 8-bit MCUs of course ...

And a C64 also worked "just fine" for personal computing too. Tell that to the facebook kids ... If your entire argument is that what was enough in the past, is enough today, we just have different "enough"s, and I really have nothing to say to you.

Edited 1 time(s). Last edit at 02/05/2015 08:14AM by arthurwolf.

Quote
arthurwolf
So are you saying a firmware designed for an 8-bit mcu, running on an 8-bit/16-20mhz mcu, will be as smooth in it's step generation and as precise in it's motion planning and execution, as a firmware designed for a 32-bit mcu, running on a 32-bit/120mhz mcu ?

Exactly. And if your firmware runs on 32-bit only, it has a flaw.

Quote
arthurwolf
I'm not even sure I understand what you are saying.

Obviously. If you had said 32-bit controllers are faster and allow higher printing speeds on more complex setups, I had even agreed. But you don't and use wobbly words like "smoother" or "better" instead.

Quote
arthurwolf

Quote
Traumflug
Perhaps some of you remember earlier high-end CNC machinery. Many of them had a 3 MHz 8-bit CPU and they worked just fine.
.

And that's exactly the reason why high-end CNC machinery today still uses 3Mhz 8-bit MCUs of course ...

Actually I know quite a number of machining shops which still run these 30 year old controllers. Because it's simply pointless to replace them. Except for saving electricity and some workshop space, perhaps.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Guys

Can we please all agree to disagree and put this to Bed it is getting a little out of hand now.

just my thoughts.

Yup. Not a surprise, but you just confirmed trying to reason with you is a waste of time, so as everybody has been advising me to do, I'll stop trying ...

And next time you publicly claim Smoothie has nothing for it other than it's marketting, or that moving to more powerful microcontrollers has no gain, I'll just link people to this post. Enough explained here.

Edited 2 time(s). Last edit at 02/05/2015 10:22AM by arthurwolf.

Please lets calm down again. We are not too far from each other.

Quote
Traumflug

Quote
arthurwolf
So are you saying a firmware designed for an 8-bit mcu, running on an 8-bit/16-20mhz mcu, will be as smooth in it's step generation and as precise in it's motion planning and execution, as a firmware designed for a 32-bit mcu, running on a 32-bit/120mhz mcu ?

Exactly. And if your firmware runs on 32-bit only, it has a flaw.

C is not as platform independent as always claimed. So having something that runs on 8 and 32 bit is unrealistic. It might be possible, but it then can not be high performance on both chips. And the bad performance of Marlin is your argument, so this is is a bit unfair. Especially as I haven't seen Teacup run on anything 32bit.

Quote
Traumflug

Quote
arthurwolf
I'm not even sure I understand what you are saying.

Obviously. If you had said 32-bit controllers are faster and allow higher printing speeds on more complex setups, I had even agreed.

So here we have it. You both agree that faster clocked chips can achieve higher step rates and support more complex setups.

There are two points that not have been mentioned before:

- writing software that performs better than other software on the same processor is harder to do. So being able to do such a thing is something to be proud on. But for the community as a whole it also makes sense to have an easily hackable platform that still has good performance.

- The prices of 32bit chips dropped a lot in the last time. They sell cheaper than 8 bit chips. This is not too important to the single maker but this is still relevant especially for the future. ATmel already stopped working on the 8bit AVR. There will be no more new chips coming from them. So in a few years (ok more like 5 to 10 or more) getting a AVR will become harder with ARM Cortex-M being everywhere,...

Besides I haven't seen any argument why a 32bit chip should be worse than an 8bit.

Quote
JustAnotherOne

Quote
Traumflug
Obviously. If you had said 32-bit controllers are faster and allow higher printing speeds on more complex setups, I had even agreed.

So here we have it. You both agree that faster clocked chips can achieve higher step rates and support more complex setups.

Yep, we clearly agree on that, as it's obvious.
But he goes further than that. He implies that a higher step rate and more complex setups are the -only- benefits from the Smoothie system, when they are in fact not.

Quote
Traumflug
But you don't and use wobbly words like "smoother" or "better" instead.

See ?

Smoothie is actually in fact smoother ( you can tell from the name that it was actually an intended goal ). We can break arcs into smaller segments, we can do better planning math, better acceleration, better step generation, we do many things in a way that is -in fact- better.

Just an example : Smoothie does not just do "faster" step generation, it does "better" step generation : the step interrupt is run at a constant 100khz and the other axes follow that, resulting into smoother ( smoother here means "less rough", or if you prefer "closer to an ideal theoretical step pulse", is that still too "wobbly" of a term ??? ) step generation compared to the classical bresenham step generation ( where slower axes follow the faster axis ).

And that's just one thing amongst many others. Combined, all these result in faster, quieter, more "correct" ( again as in : closer to ideal ) printing with less artifacts.

And that's just the planning/step generation, here I'm ignoring the many many actual additional features. And that's ignoring the fact that the more powerful chip -also- allows us to make a firmware that also supports CNC routers and laser cutters, resulting in a wider ( as in : more diverse ) community, resulting in more collaboration/contributions, which in my eyes, has a -lot- of value.
I'm also ignoring the fact that technically, being "faster" also potentially means being "smoother" as it allows for higher microstepping ( which lots of people seem interrested in lately ).

Years of work has gone into taking better benefit of the more powerful chip.

Edited 2 time(s). Last edit at 02/05/2015 12:14PM by arthurwolf.

Quote
arthurwolf
Just an example : Smoothie does not just do "faster" step generation, it does "better" step generation : the step interrupt is run at a constant 100khz and the other axes follow that, resulting into smoother ( smoother here means "less rough", or if you prefer "closer to an ideal theoretical step pulse", is that still too "wobbly" of a term ??? ) step generation compared to the classical bresenham step generation ( where slower axes follow the faster axis ).

And that's just one thing amongst many others. Combined, all these result in faster, quieter, more "correct" ( again as in : closer to ideal ) printing with less artifacts.

Likewise, printers running Duet electronics sound smoother since I changed the firmware from using the Bresenham algorithm to calculating the step times precisely (to about the nearest microsecond) - for example, see [forums.reprap.org]. The limiting factor in achieving this is the time taken to calculate the square root of a 64-bit number, which needs to be done for every step during the acceleration and deceleration phases. The generation of steps for linear delta moves requires a further square root for every step. There is no way that an 8-bit mcu would be fast enough to calculate these square roots.

I'm not disputing that 8-bit MCUs can be used to control 3D printers, but I believe they are far from an optimal solution.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].