Smoothie-ware

[MSURunner]

Has anyone looked at smoothie firmware in a delta configuration? Just lazily seeing if anyone has done it to make an experiment with an ARM board easier. The benefits of ARM for delta's would be huge...

[cope413]

I was a Kickstarter backer and I just got shipping notification, so I'll have my Smoothie board within the next week.

I've looked at the delta info, but obviously haven't done anything with it yet.

I'll definitely be sharing the results when I get it going.

[Eaglezsoar]

I was a Kickstarter backer and I just got shipping notification, so I'll have my Smoothie board within the next week.

I've looked at the delta info, but obviously haven't done anything with it yet.

I'll definitely be sharing the results when I get it going.

Great news on the smoothie board. Don't forget the Rods and Bearings alterations for the Max.
I am really interested in a mod like that.

[cope413]

Didn't forget

Waiting for the smooth rods I ordered to show up, but here's the part I designed to fit over the extrusions and hold the rod...

RMax Smooth Rod Support_v1.STL

(77.62 KiB) Downloaded 365 times

I printed them in ABS at .1mm layer height and they came out really, really nice. They fit very snugly over the extrusions. I'm going to make the slot for the belt a little wider, but I don't think that's an issue.

I haven't finished the design for the sleeve bearing holder yet, but it will both hold the bronze sleeve bearing in place, and space the carriage plates out properly.

I plan on documenting everything and posting it as soon as I get it all going.

[int2str]

The benefits of ARM for delta's would be huge...

Says who?
What benefits?

[cope413]

Lots of benefits...

Read about it here.
http://smoothieware.org/smoothieboard

[626Pilot]

Says who?
What benefits?

The RAMBo and similar controllers are based on a 16MHz microcontroller with 4K RAM and no ALU (math coprocessor). They're great chips, but the low clock speed and lack of acceleration for floating point math means that the code has to be very carefully optimized. For example, the floating point divide instruction was redone in hand-coded assembly language because it just wasn't fast enough before. There has been at least one bug in the Repetier firmware (stuttering when you set the print speed to less than 100%) that can be traced directly to these constraints.

With an ARM processor, you get much higher clock speed, more RAM, and more than likely some acceleration for floating-point math. (If not, the higher clock speed helps to compensate.) Adding features and changing existing code is less frightening because you don't know if what you're messing with is one clock cycle away from throwing everything into disarray.

It is also possible to calculate more accurate movements with delta robots. Right now, everything is done in Cartesian... and then translated into delta movements something like 200 times/sec. With a bigger processor, you can do translations more frequently or just work with delta coordinates natively and skip the timed translations.

[Flateric]

I'm an early backer as well, hrm, no shipping notification for me.

I must rattle some cages it seems.

[int2str]

Lots of benefits...
Read about it here.
http://smoothieware.org/smoothieboard

Not seeing it? What am I looking for?

The RAMBo and similar controllers are based on a 16MHz microcontroller with 4K RAM and no ALU (math coprocessor). They're great chips, but the low clock speed and lack of acceleration for floating point math means that the code has to be very carefully optimized.

You say that like it's a bad thing

It is also possible to calculate more accurate movements with delta robots. Right now, everything is done in Cartesian... and then translated into delta movements something like 200 times/sec. With a bigger processor, you can do translations more frequently or just work with delta coordinates natively and skip the timed translations.

Not to sound too much a contrarian here, but I still am not seeing the argument. Of course more computing power is always "better". But that's the argument that gave you MS Windows .
I've not seen any true limitation of the Atmega2560 being hit yet. And I've seen the code (and modified it). It still has room for improvement.

At the very heart of it is a simple fact tough - "all" the controller/chip has to do is to send pulses to 4/5 stepper motor drivers at a certain frequency. There is a point where you can't do that any faster. The extruders won't be able to keep up, the mechanics will be the limit etc. I'm not sure we've seen the limit yet.

As for your cartesian vs. delta argument, again I'm not quite understanding the argument. GCode is in X/Y/Z coordinates. Yes, that has to be translated to delta motion, but that's not entirely different from a Cartesian printer either. Though admittedly the math is a bit more complicated for a delta. If you want to optimize it you might as well have the X/Y/Z to "delta" calculation done on the slicer instead.

When you say "calculate more accurate movements" I'm just not sure what that means, or where the actual limit is. So far I've not seen any proof it's the ATmega core. Floating point math is over-rated. I'd rather use integer math internally anyway. The final unit will always be a (micro-) step anyway.

The RepRap firmwares are still in their infancy as far as computer software goes. We're past the "get it to work" stage. Now the experts can optimize it, enhance it and get the best out of it.

Anyway, as I said, more power is always better. But if you think that an ARM core is going to magically transform your printer, I'm just not convinced that's the case. As a professional software engineer, I'd like to see some hard evidence on the timing involved and the limits encountered first.

Bigger and better chips also mean more complex APIs and more complex development (don't even get me started on multi-threading etc.).
Let's hope we can keep things simple and not end up with "Windows 8 for 3D printers" any time soon

[Eaglezsoar]

int2str, don't let them kid you. They just like to have the latest and greatest toys and I am jealous.

[626Pilot]

Not to sound too much a contrarian here, but I still am not seeing the argument.

Then read it again.

[neurascenic]

As I understand it, one of the best advantages of this is that it has the power to look ahead. that is to plan it's acceleration and deceleration on the fly.

too, for non-professional coders, a little slop is a good thing (ok, a double edge sword)

For me, however, is the idea that this board/firmware can be adapted to other projects by design.
it isn't the power of the machine that gets to be leveraged, but the power of my knowledge (even if it is limited)

Sadly, I missed the Kickstarter by a couple of days.

[geneb]

The .91 release of Repetier-Firmware includes a "Due" branch that is targeted at the AVR based Arduino Due. Will that code work on the Smoothie board?

A faster controller means smoother and more precise motion. Having the horsepower to do effective motion look-ahead is a big win as well.

You only use integer math when you don't have any other choice. Yes it's faster, but you lose a lot in precision.

g.

[cope413]

I think this graphic is very informative.

In simple terms, we're not getting everything out of our current hardware because we lack the processing power to plan properly. ARM boards will change that.

http://smoothieware.org/howitworks

[Eaglezsoar]

I think this graphic is very informative.

In simple terms, we're not getting everything out of our current hardware because we lack the processing power to plan properly. ARM boards will change that.

http://smoothieware.org/howitworks

Now that the boards are appearing what is your time estimate for the firmware / software to take advantage of the increased power?

[int2str]

Not to sound too much a contrarian here, but I still am not seeing the argument.

Then read it again.

Hard to argue against that kind of logic :p

A faster controller means smoother and more precise motion.

This is the part I have the most trouble with.
That would only be true if the Atmega had reached the limit for being able to saturate the stepper motor drivers.
Is that the case?
Any timing analysis done?

Again I'd like to point out that I'm not argueing against having more horespower, I am simply not seeing the fact yet on how that would help.
The planning argument I could almost understand. I'd still like to see how saturated the controllers currently are.

The Smoothie web site only throws around marketing level arguments - not a whole lot of facts....

[MSURunner]

Wow, that took off quickly. I guess to toss the benefits in that I would say are huge for the deltas would be largely the planning process. It's really easy to look at accelerations of the head and plan for those (looking at the g-code values in the file), but the math associated to figure out the accelerations for the corresponding tower moves, especially when you are modifying the speed multiplier, can bog down a Mega. Additionally, the extra processing power could unlock benefits in ALL bowden based printers by better monitoring and planning for extrusion needs and head pressures to produce better results (and potentially color mixing with multi-filament extruders). That look ahead capability is beyond what a current Mega board can handle.

Cope have you downloaded and looked through the firmware then? Does it look reasonably well documented if not attempted elsewhere?

[GeraldO]

What I'm looking forward to most out of these new platforms are that we have the spare cycles and available memory to actually write clean(er) code. A lot of the printer firmwares, although readable, aren't really the easiest things in the world to get used to tinkering with. Looking at that article I can see that there would be a good usage of interrupts, objects and callbacks, which are awesome!

Definitely looking forward to hearing/seeing more from the smoothieboard, but at the same time kind of dreading the arms race to be the next RAMPs board for next gen printer hardware.

[int2str]

What I'm looking forward to most out of these new platforms are that we have the spare cycles and available memory to actually write clean(er) code. A lot of the printer firmwares, although readable, aren't really the easiest things in the world to get used to tinkering with.

Cleaner code would be nice. And indeed, looking at the Smoothie code, it's rather clean overall (minus hard coded strings, use of std::string etc.).
That is not to say that a firmware for ATMega couldn't be just as clean. Look at the "Cosa" framework for Arduino for example.

Anyway, looking forward to see what comes of this.

[626Pilot]

Here are the specs for the CPU they're using: http://www.nxp.com/documents/data_sheet ... _64_63.pdf

• ARM Cortex-M3 based microcontrollers
• The LPC1768/67/66/65/64/63 operate at CPU frequencies of up to 100 MHz
• The LPC1769 operates at CPU frequencies of up to 120 MHz
• 3-stage pipeline and uses a Harvard architecture with separate local instruction and data buses as well as a third bus for peripherals
• Internal prefetch unit that supports speculative branching
• Up to 512 kB of flash memory capable of 120 MHz operation with zero wait states
• 32/16 kB of SRAM on the CPU with local code/data bus for high-performance CPU access
• Two/one 16 kB SRAM blocks with separate access paths for higher throughput which may be used for Ethernet, USB, and DMA memory, as well as for general purpose CPU instruction and data storage
• Ethernet MAC
• USB Device/Host/OTG interface
• 8-channel general purpose DMA controller
• 4 UARTs
• 2 CAN channels
• 2 SSP controllers
• SPI interface
• 3 I2C-bus interfaces
• 2-input plus 2-output I2S-bus interface
• 8-channel 12-bit ADC
• 10-bit DAC
• Quadrature Encoder interface
• Four general purpose timers
• 6-output general purpose PWM
• Ultra-low power Real-Time Clock (RTC) with separate battery supply
• Up to 70 general purpose I/O pins

I will add the example that our printers sometimes stall when running over USB because the AVR's minuscule 4K RAM (which is shared with other things) can only hold so many lines and only has so much time available to pull new lines out of the buffer. With this CPU, there is no reason why the buffer couldn't be 64 lines long, or 512 for that matter. That makes things like arc inference easier to do. If we don't want to use USB, we can use Ethernet instead, opening the door to letting multiple computers access the printer the same as they would a laser printer. (The firmware has a Web interface for that purpose.)

The processor also costs significantly less than the less capable ATMega2560 does.

Overall, this is like the difference between a clown car and a Cadillac, or the difference between having $4 and having $64. Maybe you like clown cars. Feel free to use the RAMBo.

The .91 release of Repetier-Firmware includes a "Due" branch that is targeted at the AVR based Arduino Due. Will that code work on the Smoothie board?

It would probably require some porting and I don't know how well-tested the ARM code is, but it could work. I'd probably try the Smoothie firmware first and only change to Repetier if it was too annoying or lacked some feature I needed.

[626Pilot]

I think this graphic is very informative.

In simple terms, we're not getting everything out of our current hardware because we lack the processing power to plan properly. ARM boards will change that.

http://smoothieware.org/howitworks

Is this board expandable? I'd eventually like to have something capable of driving four extruders.

[MSURunner]

Is this board expandable? I'd eventually like to have something capable of driving four extruders.

It's not an ARM board but http://www.panucatt.com/Azteeg_X3_Pro_p/ax3pro.htm

Here's a Smoothie alternative that those guys also make and they have a history of building expansions on their boards, so while their first iteration only would support dual extruders, I would keep an eye on them. Incidentally, this is the board that I had in mind when starting the conversation... http://www.panucatt.com/azteeg_X5_mini_ ... x5mini.htm

[cope413]

There are a bunch of unused pins for "extension fun", but they haven't provided much in the way of details yet. Focused on getting the hardware out first, I'm sure.

[Eaglezsoar]

There are a bunch of unused pins for "extension fun", but they haven't provided much in the way of details yet. Focused on getting the hardware out first, I'm sure.

When I go to the site for the smoothie I did not see one offered with the Ethernet connector in place or even as an option. Am I blind as an earthworm or is that a future feature?

[Apollyon25]

At work we use the ST Microelectronics M4 ARM. Specifically the STM32F405RGT6.

We initially looked at the ARM that is used in the Smoothie board, however ST were upgradable, pin compatible and cheaper. We also found loads of bugs in the silicon around DMA and ADC timings in the LPxxxxx.

With this bit of STM32 silicon goodness we capture 12x 524 sensor values, process the images, determine locations, reject 'virtual' coordinates and output up to 10 real-time, ~120Hz touch locations. As well as sending this over USB, having a fully configurable system, sending measured waveforms blah blah blah...

In short, ARM based platforms are very good (M4 especially). The ATmega2560 is frankly a bit of a hobbyist micro-controller.

I recently had little blobs appearing in my prints and it wasn't til I was running much faster (100mm/s - which I know is not super fast for a delta) I was seeing these little movement stalls as the code ran off and got some more data from the SD. I should say at this point that I also had pronterface connected, so some of this processor load may have been servicing the comms traffic to this.

I'm keen on getting one of these Smoothie boards when they are readily available and a FW colleague of mine (responsible for much of the magic occuring above) is keen to port it and make it run fast and efficiently.