Stellar results on 20x Barth Sextic

2/28/2015

green20xbarth_hq
With the great success on Wednesday's small Distel print, I decided to plunge ahead with a large Barth Sextic. 20x is pretty big, having an 80mm bounding cube. I used priming walls, both to prime the nozzles, and to catch any errant oozing from idle extruders.

Total print time: 31 hours, 47 minutes. 0.2mm z-resolution. Green Ninjaflex at 213°C, PVA at 183°C.
Stacks Image 1013
Stacks Image 1009
Stacks Image 1011
Best NinjaFlex detail resolution so far

2/26/2015

I've really got the TAZ printer tuned! After ruining part of the carriage for the Flexy Dually, which I had printed from PLA initially, and reprinting it from ABS, I have fully recalibrated the machine, and it's really great now!

Using two sacrificial walls to catch ooze drips and prime the two nozzles, I can print details such as on this 10x distel, where the six points of the star taper to such fine features that I think they should not even be printable. Not only that, but since NinjaFlex is flexible, the movement of the object as it is printed can hinder small details. The material also strings a little, so I had to really get retraction settings perfect to get this little guy to print.

Shown here against a CR2032 battery for size.
Stacks Image 1090
std::complex with high-precision numbers

2/23/2015

If you write a custom number type with a conversion operator to double or a double-related type, beware using that type in std::complex. The standard implementation of complex numbers is only valid for types float, double, and long double, as noted in this documentation.

Here is what I observed. I created 100-digit numbers in my custom class, and then used the numbers in the std::complex class. I then did some tests (thank you Boost.UnitTest), and discovered that the absolute value of the complex number (1,1), when compared to sqrt(2), differed at the 17th decimal place, right where they would if there was a double conversion somewhere along the way.

An implicit conversion to double() was taking place somewhere along the way, so all the hard work that went into creating 100-digit numbers was for naught. The temporary conversion was masked by a reconversion into a 100-digit number, just with junk after the 16th digit.

Moral of the story -- don't use anything other than a float, double, or long double in the std::complex class, especially if you allow conversions to double. Strange things will happen!
Eigen using a custom number type

2/20/2015

I have been successful in using my custom number type in the Eigen linear algebra library. I simply needed to ensure that the type has all the arithmetic operations defined, including the '+=' style operators. In fact, it is more efficient to define the regular '+' in terms of '+=', and it simplifies the code!

I now can perform LU decompositions using adaptive multiple precision. I am checking off linear algebra for the TODO list for Bertini 2.
Boost.Multiprecision has a subtle and potentially serious bug in it, version 1.53

2/18/2015

While Matt Niemerg and I were testing the Float class for Bertini 2 today, we ran across a bug in Boost.Multprecision. Using Boost 1.53, creation of a boost::multiprecision::mfr_float, and changing its precision, results in incorrect precision reported. Namely, if you make a boost::multiprecision::mfr_float a;, and then change its precision, a.precision(20); or whatever, it will subsequently report an incorrect number of bits, not the correct number of digits, in the stored number.

See this bugreport for a few more details.
A second Barth Sextic

2/9/2015

I successfully printed a second 20x scale Barth Sextic, this time in the Water color NinjaFlex. The Water color is significantly more oozy, so there were a lot of bits hanging on to the outside of the print, especially on the support material.

This is the first Barth Sextic I have printed which had all the 'cones' attached after removal of support material. I feel pretty good about that. The only mistake this time was that I didn't extrude enough material after changing the reel, so the bottom is slightly orange tinted. Lesson learned.
Stacks Image 1320
Machine tuning getting pretty tight

2/5/2015

three_orange_small_kleins
I have now printed a few Barth sextics successfully, but am getting some cruddy issues on the underside of the print, where it interfaces with the support material.

This morning, I set out to resolve these issues. There was one major outstanding issue -- the support extruder was overextruding. I have played with adjusting the 'flow rate' modifier, but it's hard to get that dialed in because I cannot easily change it for just one extruder during the print. So, I went back to the extruder steps per mm setting in the firmware for the printer. The number was set at 996.x. Huh? I had set that as something else a while ago, and it lost it!

Oh yeah, you've gotta save the changes to the machine or when it power cycles or disconnects and reconnects, it loses unsaved settings. Ok. So, I used Triffid's calibration guide with the 5mm step object, and got the Esteps narrowed in to 916steps/mm. I now have much better underside contact with the print, and a lot less mixing.

Observe the image to the right. From left to right, you come forward in time. Early prints were not only improperly calibrated for extrusion steps, but had incorrect settings for head offsets in the firmware. I have since adjusted both settings, and now have pretty good undersides!

I am printing another copy of the klein-like object at 10x, having adjusted the retraction settings for both extruders. Here's hoping that the next one comes out almost perfect!
Barth Sextic #2

2/3/2015

orange_barth_support
My second sextic completed this morning, and the support is now dissolving in hot water. I used what I learned from the first one. I turned up tool-change retraction to 7mm, turned up the support print speed, and put down fresh tape. The blue painter's tape works like a charm!

I used the same model, scaled to 20x, so the bounding box is 80x80x80mm on this one. Total print time: 16:40. There is still some stringing for the PVA. I'll have to increase the retraction for the PVA extruder.

Overall, I am very happy with the setup now. Good adhesion, nice generated supports, decent print time. I'll keep working to see how fast I can print, while still getting good results. Printing a Barth Sextic the size of a volleyball is an intimidating challenge, and I'll only be able to do it if I can get the speed higher. Otherwise it'll be a 1-week print!
orange_barth_support_in_progress
orange_barth_support_on_table
My First Barth Sextic

2/3/2015

orange_barth_3
I completed a Barth Sextic print yesterday, using the dual extruder head for the TAZ4. I used my decomposition and refinement of the surface from several months ago, thickened in Blender to 0.2, decimated by a factor of 0.1, and passed through Netfabb's online service.

Printed at 10x size, for a bounding box of 40x40x40mm, using lava NinjaFlex as the model material and PVA support, this surface looks pretty nice!

There is some stringing of the PVA, which I don't really care about, except that the strings may pass across the model surface and contaminate the plastic. So I've gotta fix it. Print time: 3:45. 0.2mm thickness. 190°C for PVA, 212°C for Ninjaflex. And printed pretty dang slow! 6mm retraction between tool changes, 2.6mm retraction on both heads between moves. Used generated support from Simplify3D, and I am pretty pleased with it. 50% fill on the support, with two angles - 0° and 90°.

The support dissolved overnight, but I started picking at the support before it was soft, and two of the 'cones' broke off. I reattached them using extruded plastic from the machine.
Stacks Image 1544
orange_barth_4