My first Smoothieboard prints, wow!

[Flateric]

[img]http://i.imgur.com/Jj5sSOS.jpg[/img]
[img]http://i.imgur.com/SKq3lb4.jpg[/img]
[img]http://i.imgur.com/DCGNfn1.jpg[/img]
[img]http://i.imgur.com/mgnYB80.jpg[/img]

I can't believe the step up in quality changing away from arduino has made.

Did not expect the finish to go up so much.

Even the polygon stepping pattern that usually works it's way through is entirely gone. 22 mins to print the plus vase BTW, .25 layer height so nothing crazy either.

[Jimustanguitar]

So the elephant in the room is... Do you have any parts printed with identical GCode from the Arduino setup for a before/after comparison?

[Flateric]

I don't but I am never going back, lol.

http://flat3r1c.imgur.com/all/

[lordbinky]

AAannnddd I'm putting mine together this weekend for sure. It also helps I may have abused my Rambo for the last time since squares are looking diamond shaped after my rebuild and I can't find a physical reason to it as well as being stuck on the Z stepper driver.

[lordbinky]

Are you using .9 stepper motors?

[bubbasnow]

dayum that looks sweet!!!! i want a full write up before you go to bed tonight

kthanks

[JohnStack]

Honestly, I don't understand. Well, maybe I think I do but...

Ok, you have a processor board with servo controllers. It's different than the Rambo.

How so? Better interaction between the controller / processor and the servo controllers? More even power?

What are the top three values to adopting a Smoothie?

And then:

When I finish all of my Mini-Kossel, I'm all over this!!! Whee!

[Glacian22]

As I understand it, the huge boost in processing power turns into better prints by way of finer grained delta calculations, ie curves on a Rambo look more like a series of line segments, particularly at high speeds, whereas it should always look super smooth with an ARM based board.

[Tinyhead]

Is the idea similar to the Beagleboneblack, but just all contained on one board vs. add on boards?

[Brian]

Is the idea similar to the Beagleboneblack, but just all contained on one board vs. add on boards?

The Beaglebone Black CPU is between 10 (1GHz vs 100MHz) and 500 (Hardware Floating Point vs Software Floating Point) times faster than the NXP Micro on the Smoothieboard, so if going from AVR Based Rambo to Smoothieboard gives this kind of improvement, then skipping right to the BeagleBone Black seems like a no brainer! Is someone working on a BeagleBone Black based controller that will fit the R2?

BeagleBone Black has native hardware support for 1080P LCD Touchscreen with 3D graphics accelerator GPU too! (Drool!)

[Chrissi]

The question I have to ask though is what did you slice it with as well? The nude appears to have G02, G03 radius moves rather than the G01 facets we are all used to, question is can the RAMBO handle this sort of move or does it take Smoothieboard power to do so?
All this time I had been thinking it was the slicer programs were not that sophisticated yet.

[enggmaug]

I'm just posting a message here to make sure I don't miss the future answers to all the questions being asked until now.

That looks promising... but now that I am upgrading to the Kraken, and spent a lot of money on it, I won't upgrade to a boards that does not have the capabilities to drive 4 heads.

[bvandiepenbos]

WOW, WOW, WOW nice print! no way you will ever get that nice with Arduio based controller.
I suspected it would be better, but not that much better.
I was planning on going to something else eventually, but now it just got bumped to a much higher priority.
My NEMESIS Air Delta needs this!
Probably going with a Beaglebone.
People are developing for 3D printers...
http://blog.machinekit.io/p/hardware-capes.html

edit 4/15/14:
decided to go with the smoothie.
just ordered the 5 driver version.
looks to be a simpler option than messing with BBB, Cape, linux, EMC2.

[JohnStack]

Honestly, I'm not there on the logic - CPU for smoother moves?

Imagine this:

You write a program in C that executes floating point calculations to a certain level of precision. It's open source.

You run the program on a single core X86 and print the result (stdio).

You take the same program and run it on an Arduino (assuming the same precision).

You run the program on a quad core x86 and print the result (stdio).

Please tell me that the software is the same and that the real value is in signal processing on the board itself....otherwise, my head might explode.

[bubbasnow]

WOW, WOW, WOW nice print! no way you will ever get that nice with Arduio based controller.
I suspected it would be better, but not that much better.
I was planning on going to something else eventually, but now it just got bumped to a much higher priority.
My NEMESIS Air Delta needs this!
Probably going with a Beaglebone.
People are developing for 3D printers...
http://blog.machinekit.io/p/hardware-capes.html

i got a bebopr++ coming to me it should be here in a week

[Brian]

Honestly, I'm not there on the logic - CPU for smoother moves?

Imagine this:

You write a program in C that executes floating point calculations to a certain level of precision. It's open source.

You run the program on a single core X86 and print the result (stdio).

You take the same program and run it on an Arduino (assuming the same precision).

You run the program on a quad core x86 and print the result (stdio).

Please tell me that the software is the same and that the real value is in signal processing on the board itself....otherwise, my head might explode.

There's the rub.

The BeagleBone black runs a 32-bit CPU at 1000MHz clock speed and has a floating point coprocessor.
The Arduino runs a 8/16 bit CPU at 16MHz and has to do all floating point in software.

The precision of the calculations you do on the arduino is bound to be limited by the speed of the CPU. Remember that the CPU has to do everything in the system. It's reading the I/O's displaying the User Interface, directing the steppers, and it has to keep up with a lot of those in real time. I'm just getting into this, but the CPU must be calculating the speeds of the steppers and adjusting it at some timed interval, and synchronizing all of the servos to move at the same time in that same interval. The Arduino has to keep up with all the real-time operations as well is do the floating point math at the same time. It may very well be using less precision in the math just so that the CPU is not getting bogged with the math. The Beaglebone CPU is doing real hardware double precision floating point probably 1000 or more times faster than the Arduino, so it can serve the real-time operations at a much shorter interval.

An analogy would be to pretend the real-time task of the Arduino is like the framerate of a videogame. The faster the CPU, the shorter the interval and the higher the framerate. An old PC running a recent game release will be doing the same math with the same precision and updating it at a much slower interval, so your eye sees staccato choppy movement on the screen. The same game at the same precision will have a much faster refresh rate and your eye will see this as smooth fluid motion.

I believe that since the extruded plastic has to move at a fixed rate to provide a layer of desired properties, the extruder must move at that rate no matter what. So if the extruder is making a circle and the Arduino is able to update the servo positions 100 times as the circle is traced, you will see 100 discrete points on the circle that the motors changed speed. A CPU that is 10 times faster will be able to update the motors 1000 times at 1000 discrete spots as the same circle is traced out by the extruder. Since the extruder is moving at a speed that is fixed by the plastic and nozzle diameter specs each circle takes the same time to complete, but one of them is made up of 10 times more motor position updates.

This is how I understand this all works. The CPU can play a big role in all this. Imagine a CPU that is tuned to the geometry and mass of each component in the printer and can take the movements on the fly and adjust or even leverage to an advantage the momentum and mass of all the moving parts? This is where a great CPU will make a great printer even greater.

For what it's worth, the CPU inside the Beaglebone Black has embedded INSIDE of it not one but TWO completely independent addon CPUs that are designed to do only things that happen in real-time. The main CPU doesn't even have to worry about real time processing. Each of these runs at 200MHz, so they are each 12.5 times faster than the Arduino.

I really didn't get into the amount of memory on each of these boards, but as I understand it there's little storage on the Arduino and you have to recompile the software to make parametric changes. Imagine a board that could simply save all that to flash memory and call up a material "profile" that was tailored to a specific spool of filament and then be able to print in "draft" mode or "high res" mode by pressing the choice on your screen? This is what BeagleBone is going to bring to the party.

[Flateric]

^^This makes alot of sense. One of the values in the config file is how many times per second the speed is checked during printing. The default value for this out of the box is 1000.

My steppers are the as shipped 1.8 degree guys and other than this my machine is not really remarkable other than being upgraded with the magnetic arms.

I was however really thankful I had hammered out all the delta radius value and towers being leveled in repetier firmware simply because these are not "hot" changable things with the smoothie in realtime like they are in repetier. However these value did directly input into my smoothie config file directly and that spiral vase is direct proof. It was the very first thing I have ever printer with the smoothie. The nude torso print failed due to an unfortunate cat unplugging my power incedent.

I did not think the quality jump would be this huge myself. I thought I had pretty much reached the best my printer could manage with the repetier firmware and ardunio hardware. Thinking the upgrade would allow higher speeds (which it certanly does also) was my main goal.

I had tried 0.9 steppers in the past but saw nowhere near this level of improvement and had serious hardware problems feeding them the movements with reliability.

After my astrosyn damper discovery and xnaron getting my failed magarms attempt on the rostock max (inspired by berry bot) this is the best upgrade ever. Really takes the printer well into professional quality printing.

The azteeg X3 was my fav arduino based controller because of it's really top notch quality, I imagine the X5, which is smoothie based and comes with examples in the smoothieware download package will be excellent as well. I got a genuine smoothieware board and it is also really nicely done.

[mhackney]

Spectacular results! Did you get the 4X or 5X? The little azteeg X5 has 32 micro stepping drivers, that's nice, but only 4 stepper drivers.

[mhackney]

Flateric, I saw this on the smoothie ware site:

arm_length and arm_radius can be set live using M665 L340.0 R240.5 where L is the arm_length and R is the arm_radius… home must be called after setting these.
M665 on its own will just report the current settings.

There is a configuration file that smoothieware uses and it appears that you can set values (or some of them) in that file like above. But, it appears you have to reboot. This at least eliminates the compile step. Is this how it works? I'm very interested in one for a mini kossel I'm building.

[Brian]

^^This makes alot of sense. One of the values in the config file is how many times per second the speed is checked during printing. The default value for this out of the box is 1000.

I'm a n00b at the 3D printing end of things, so I am only speculating based on what I know from other applications I have worked on. I would guess there's some kind of legal limit to how large you can make that number for any given processor. If you set it to 100 times a second does the print quality suffer? If you set it to 1,000,000 times a second, does It give an error code or fail completely? Or, does it just run as fast as it can once you set the setting higher than the hardware is capable?

For all we know, the speed is tested 500 times a second max because that's all the poor ATMEGA on Arduino can take, and the setting is set for 1000 and is making no difference. Load the same code into a CPU that's 10 times as fast and all of a sudden the 1000 means 1000 for real.

I'd be interested to know what the story is. I think my first mod will be to upgrade the CPU when I buy my Rostock. I will likely build to the OEM design and learn calibration and use and get familiar, then go right to the CPU upgrade.

I hope you guys will do some write-ups on the software installation needed for the upgrades.

[Flateric]

This was for certain a big part f the problem, the arduino would simply be unable to keep up with the printers demands, especially at the higher speed the hardware config of the delta design allows for and excells at doing.

With my setup I can actually see the limited resolution of the curves and almost what I would call "pixelization" of curved and large flat surfaces. It was a pattern much like a moire pattern. I'll print something with my new setup that this pattern showed in before and post pics. I had previously always thought it to be a hardware ringing or resonation sneaking through.

[bubbasnow]

This was for certain a big part f the problem, the arduino would simply be unable to keep up with the printers demands, especially at the higher speed the hardware config of the delta design allows for and excells at doing.

With my setup I can actually see the limited resolution of the curves and almost what I would call "pixelization" of curved and large flat surfaces. It was a pattern much like a moire pattern. I'll print something with my new setup that this pattern showed in before and post pics. I had previously always thought it to be a hardware ringing or resonation sneaking through.

have a mod make a subforum and post your stuff!!

[Brian]

The patterning you mention could easily be caused by a low refresh rate. It makes perfect sense. Has nobody ever had this discussion before? It seems pretty obvious that the delta is doing more work because all 3 steppers move in concert at all times, where a Cartesian printer would only change the Z axis between layers, and so only 2 steppers are updating during the layer print. This must tax the arduino more than in other situations and result in small positioning errors that form patterns in the output. This all seems very fixable.

By the way, how do ARM based boards compare in price to the Arduino boards? ATMEGA MCUs always seemed to be way overpriced to me.

Can you print something smaller and more detailed as well? With a scale for reference? I can't tell from the photos how big the objects are to get a sense of scale.

[Flateric]

Yup discussion has occured before, the deltas also tax the cpu with more complicated calculation as well as running more motors at a time.

My smoothie in the end was the exact same price as a Rambo.

Yes, I'll be post a few more examples as I go.

[Brian]

Does the smoothie work with the same LCD front panel and whatnot? Or do you lose features when you use it?