Smoothie M2

[Tim]

Okay, first result is from the Thingiverse ripple test suggested by insta.

Here is the X axis view:

Ripple effect calibration box (X axis edge)

calibrate2.png (579.21 KiB) Viewed 11846 times

Here is the Y axis view:

Ripple effect calibration box (Y axis edge)

calibrate1.png (688.87 KiB) Viewed 11846 times

and here is a view of the inside edge of a wall:

Ripple effect calibration box (inside edge)

calibrate3.png (787.55 KiB) Viewed 11846 times

I think it's worthy of a "This is your M2. . . This is your M2 on Smoothieware" epithet. Wow, it proves its point. Yes, there are ripples. But, they are so hard to see that I have to put the box in full sunlight and catch it at the right angle. The bump-outs that form right at the edge of a corner are more pronounced, but again, they are difficult to see unless you catch the light at the right angle. (edit:) On reading the preview, I think I may have actually sort of overdone it on the photographs. It is really quite difficult to see the ripples at all in most normal lighting conditions.

Printed in MakerGear black PLA with the standard (mostly default) PLA settings in S3D.

One thing I've noticed is that the Smoothieboard is not keeping a constant temperature on the extruder. I ran the PID auto-tune several times, which gave similar results each time, and I plugged in those values, but they have a severely underdamped response. Definitely not the right PID values, and while they seem to work out okay, I'd rather have a critically damped system. Possibly there is something wrong with the auto-tune algorithm in Smoothieware, but I'll have to investigate further.

Anyway, this result certainly shows that the Smoothieboard is more than just a replacement for the RAMBo.

[Tim]

And here's Jin's dimpled cylinder test result:

Dimpled Cylinder test

calibrate4.png (1.1 MiB) Viewed 11843 times

Again, the object has to be in bright light at a severe angle to see the rippling at all. I have a bit of a zit problem, but that's not the Smoothieboard's fault. Also, the print lifted off the glass on one edge, but I let it go, as that wasn't affecting the main purpose of the print.

[Tim]

I suggest a box at 100 mm/s or higher

Everything I have posted was printed with the default printing speed setting in S3D set to 100 mm/s. This is the S3D "default default". I'm not sure what S3D does with this value, exactly, in particular how it differs from the "X/Y axis speed" below it. And how both of those values interact with firmware settings for speed.

Just for the heck of it, I upped the default speed setting to 200 mm/s, with outline underspeed upped to 80%. It blew through that print at a crazy rate. Quality degrades, and artifacts become more pronounced, especially the bit of pucker at corners. In a couple of places it had a bit of difficulty making the outside corner of the box. And yet, there's hardly any ripple at all. Just the puckering, which I assume is due to the fact that pressure in the nozzle keeps the filament coming out at the same rate while the X/Y movement slows down, causing more material to be extruded than intended. Maybe this is just a matter of adjusting the "coast" setting? I feel like "coast" is not really the right thing to do---it seems like something that ought to be taken care of in firmware, by understanding the lag between making adjustments to the extruder and having the flow of filament change, and moving changes to the extruder flow further back in time, accordingly.

In the photo, it should be pretty obvious, but the one on the bottom is the same one from the earlier photos, printed at 100mm/s, and the the one on top is the one printed at 200mm/s. The one on the bottom shows the side with the indented circle, which wasn't in any of the earlier photos. I thought that feature came out especially well. It suffered quite a bit of quality loss at 200mm/s.

I'm not sure what causes the "chatter", or the very tightly spaced ripples; they occur only on the longest runs where the entire side was printed in a single sweep. I'm guessing that it's running at top speed there, and maybe hitting some sort of resonant frequency. But it doesn't happen on every layer.

Quality does degrade with speed. . . lots of speed.

calibrate5.png (1.62 MiB) Viewed 11838 times

[insta]

Shoulda had you print that same GCode on your RAMBo. Looks like the ripples are all but gone.

[jimc]

so your ripples used to be much worse with marlin? in your first post on this page, those pictures dont appear to be much better than what i would normally see but then again as you said it might look worse than it really is. makergear black pla is a very matte finish which makes ripples hard to see. the overextrusion on the direction changes is pretty severe. that was the one big complaint some of the guys i talk to have about the firmware. hopefully they will work on that.

[Tim]

What makes sense to me is that with the Smoothie processor running at something like twice the speed of the RAMBo, but running what is fundamentally the same algorithm. And given that I think that the primary cause of the vibrations is the discontinuity in acceleration caused by the trapezoid method, then the Smoothieboard gives you about the same quality as the RAMBo does when you slow it down by a factor of something like two or so. It's been noted before that the ripples get better when you slow things down, but they never disappear entirely. That's what I'm seeing here: better quality than the RAMBo at the same speed, but you can get the same quality out of the RAMBo by slowing down the print speed.

But, as I have said before, I think the Smoothieboard has the processing power to handle better algorithms; just need to figure out what those algorithms are.

[jimc]

Gotcha

[insta]

What makes sense to me is that with the Smoothie processor running at something like twice the speed of the RAMBo, but running what is fundamentally the same algorithm. And given that I think that the primary cause of the vibrations is the discontinuity in acceleration caused by the trapezoid method, then the Smoothieboard gives you about the same quality as the RAMBo does when you slow it down by a factor of something like two or so. It's been noted before that the ripples get better when you slow things down, but they never disappear entirely. That's what I'm seeing here: better quality than the RAMBo at the same speed, but you can get the same quality out of the RAMBo by slowing down the print speed.

But, as I have said before, I think the Smoothieboard has the processing power to handle better algorithms; just need to figure out what those algorithms are.

The algorithm is linear pop. If you've got the programming stones, try compiling "G2" (a fork of TinyG) to run on Smoothie.

[Tim]

The algorithm is linear pop. If you've got the programming stones, try compiling "G2" (a fork of TinyG) to run on Smoothie.

I've got the expertise; what I don't necessarily have is the time. I'm not sure if it makes more sense to port G2 to the Smoothie or try to modify the Smoothieware to do the same spline curve motion planning. The spline curve stuff in the TinyG code seems to be built on top of a basic trapezoidal planning algorithm, so that might not be so difficult to do.

[insta]

The algorithm is linear pop. If you've got the programming stones, try compiling "G2" (a fork of TinyG) to run on Smoothie.

I've got the expertise; what I don't necessarily have is the time. I'm not sure if it makes more sense to port G2 to the Smoothie or try to modify the Smoothieware to do the same spline curve motion planning. The spline curve stuff in the TinyG code seems to be built on top of a basic trapezoidal planning algorithm, so that might not be so difficult to do.

TinyG or G2? G2 is a completely different beast as far as I can tell.