My first Smoothieboard prints, wow!

[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?

[McSlappy]

Wow this is amazing. Was it difficult to get it running? I have no idea what sort of changes need to be made to switch boards - can you even use the same firmware?

[mhackney]

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.

As Flateric says, there is another discussion in another thread. We speculated that the issue might be related to math/floating point precision and that appears to be on target. That's great that you are using the 1.9° steppers and seeing this improvement based solely on math precision.

And just to clarify your "running more motors at a time" so others understand - with a Cartesian printer, once the Z level is reached all movement is in the X-Y plane and only requires moving the X and Y steppers (so 2 steppers) and this is easy Cartesian math. With a delta, all three steppers have to move to put the nozzle at a given X, Y, Z coordinate, even if the Z level is the same for all and the math is much more complicated.

[JohnStack]

^^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.

Ok, I asked Mark Cooper - when in doubt, go to the project's author!

"I don't really think that floating point timing is going to improve print quality either. The improved step timing *does* make a machine quieter but the "resolution" we are talking about from improving the step timing is pretty insignificant when compared to the print quality resolutions we can get in the first place. At a guess, your friend is getting great prints because he has a solid machine and has his settings tuned in well. Now ... for a kossel / delta style printer there actually are some basic differences in the way Smoothie moves vs. Marlin. In marlin, the speed and acceleration settings are applied to the carriages. This means the effector moves at inconsistent speed across each move. In Smoothie the speed and acceleration settings are applied to the effector itself. People I have spoken to who have used both styles say that there isn't really a quality difference in the prints though."

Ok then, we all know that floating point processors will improve floating point performance - when that's the issue -
but we're talking about devices where the triangles have already been calculated. Gawd, I would love to have the time to bench some of the arm movements.

[Flateric]

I think I may need to write him.

I switched back to the x3 last night, and quality went right back to where it was previously. Absolutely no other changes, same files, same gcode, same host, even identical firmware/config settings. The quality was not crap, it was good. But it was not stellar like it was the second I switch back to the smoothie.

How did you get ahold of him easily might I ask?

[Flateric]

As I walk around this morning making my coffee it occurs to me that even still the faster floating point does affect the print quality.

Because if you crank the speeds up on the Arduino based boards you very quickly will overload it's processor and start getting the dreaded pauses and rough movements.

Which really do ruin many prints, for me anyways.

If anyone has a specific print they would like to see, say so, and if I can find a moment I'll print and post pics.

Please nothing outragous that would take days to print. Pic something specific of smallish size that demonstrates some feature you want to see.

[JohnStack]

I think I may need to write him.

I switched back to the x3 last night, and quality went right back to where it was previously. Absolutely no other changes, same files, same gcode, same host, even identical firmware/config settings. The quality was not crap, it was good. But it was not stellar like it was the second I switch back to the smoothie.

How did you get ahold of him easily might I ask?

I PM'd you. I'm curious. I think it's the servo side of things and not the calcs. I hope Johnny is watching this thread...

I'm all for better boards and prints. I'm happy that you got the smoothy working. I ordered mine and can't wait to see it run a mini-Kossel. I've got an extra Rambo as well; so I'm very interested in seeing a comparison between the two live and in person as well.

Personally, I hope Mark has Johnny start doing his boards. Always great to see multiple options and keep the rep rappers all in the fam.

[Polygonhell]

Print a couple of 30mm high cylinders, and boxes on both setups.

I find simple prints like this are the best reflection of a machines print quality because you can easily see inconsistent extrusion and layer alignment.

The current repetier build seems to be much worse with juddery movement than previous builds and that's a function of insufficient CPU performance and certainly affects quality.

[Brian]

As I walk around this morning making my coffee it occurs to me that even still the faster floating point does affect the print quality.

Because if you crank the speeds up on the Arduino based boards you very quickly will overload it's processor and start getting the dreaded pauses and rough movements.

Which really do ruin many prints, for me anyways.

If anyone has a specific print they would like to see, say so, and if I can find a moment I'll print and post pics.

Please nothing outragous that would take days to print. Pic something specific of smallish size that demonstrates some feature you want to see.

I strongly believe the issue is in the frequency of the updates to the steppers. You can't separate this from the floating point precision in a design like this because the same CPU is trying to do both at the same time and eventually the CPU bandwidth becomes saturated and the effect is obvious.

I would like to see something small like a 1.5" tall figure like a human head or something with more intricate moves. Maybe the issue is not as pronounced on small moves than it is on large objects like your case with sweeping curves?

[Eric]

A lego brick would be a good test. Both flat and curved aspects and small enough and hollow enough to be fast.
Here's one: http://www.thingiverse.com/thing:591

[Brian]

A lego brick would be a good test. Both flat and curved aspects and small enough and hollow enough to be fast.
Here's one: http://www.thingiverse.com/thing:591

That looks like a great test.