Tuesday, March 16, 2010

Back to Plan B




After spending some time with Netfabb for Rapman Beta, I've come to the conclusion that it isn't ready for prime time. That's not to say that it won't be and that, when debugged, it won't be a brilliant piece of software, attractively priced. The problem for me is that it isn't helping me solve the sorts of printing problems that I have ... NOW.

I reached a similar conclusion about Skeinforge over a month ago. At that time I began upgrading and rewriting the Visual Basic .NET Express 2008 code in my old Slice and Dice app that I originally developed for Tommelise 1.0.

The deal breaker for Netfabb was the grim performance with respect to z-axis juddering. I did a comparison not, I'll readily admit, a completely fair one. I created a 50 mm diameter hollow cylinder and ran it first using the "very fine" setting on Netfabb. This is what I got.


This test object gives you a clear idea of the effect of the z-axis juddering.  You can also see delamination taking place on a rather large scale and you can see the attempt by Netfabb for Rapman to style some sort of cover over the top of the hollow cylinder.

Now Bogdan has rightly pointed out that a lot of my problems here stem from the fact that Netfabb prints at 260 C and wants a fan that I haven't bothered rigging.  That is not, however, the only problem that the beta has at this point, however.  For purposes of comparison, I ran the same test object through my own Slice and dice with a 0.25 mm layer setting {Netfabb at "very fine" uses a 0.125 mm layer}.  Here is what I got with Slice and Dice.


No delaminations and a much, much less pronounced z-axis juddering.  I generated the test object with Art of Illusion and used a 0.05 mm conversion of the cylinder to a triangular mesh.  That left me with a 64-sided approximation of a cylinder, if I remember correctly.  The facets are clearly visible on the Slice and Dice print and nowhere to be seen on the Netfabb print.



There was simply no comparison between the two insofar as print quality was concerned.

After the disaster that I had printing herringbone pinion gears Bogdan asked for the STL files and did quite a nice job printing them with his 0.5 mm extruder {I use a 0.3 mm extruder}.  I decided to run those through Slice and Dice, too.  While I was at it I got in and cured, not nicely mind but cured all the same, the flaw in the AoI herringbone pinion gear script that I wrote some time ago.  I will be publishing that with a download link in a few days for anybody who needs it.  Actually, you can cure the flaw with the Netfabb repair feature, which is a brilliant little facility that has saved me no end of pain and suffering dealing with STLs coming out of AoI.

That done, I did a solid ABS print of the pinion with Slice and Dice.

.
The quality is VERY good.



I printed it in about fifteen minutes including a 5 minute cooling period that I did via the simple expedient of pausing the print midway.  I've found that if you let your print get much hotter than 90 degrees you get detail blurring.

Right now I am processing the torso that I earlier attempted to print with Netfabb with Slice and Dice.  It will be interesting to see what kind of print quality Slice and Dice gives me with that art object.

2 comments:

nophead said...

Nice prints. What exactly do you mean by "z-axis juddering"?

Forrest Higgs said...

This gives you an idea.

http://4.bp.blogspot.com/_pFOm7tEWWu4/S52Y6AyM-LI/AAAAAAAACNw/XQfNT1NU9Ic/s1600/DSC00006.JPG

It's a compression and expansion of layers in a print that oddly enough operates at the same pitch frequency as the lead screws controlling the z-axis.

There is a big debate going on over at the Rapman forums about how this is happening. It seems to be a mix of mechanical and gcode generating apps as best as I can see.

It's been hanging around at a very low level for some time but got a lot of new press in the forums with the beta testing that we've been doing on the new Netfabb for Rapman gcode generator.

The degree to which juddering becomes apparent seems to be closely related to the layer thickness being printed.