Testing the envelope

This has been a pretty frustrating week.  Last week I got a long way towards evolving a thin-walled approach to making post-tensioned, composite structures which could support herringbone rack and pinion systems.  This week I wanted to push the post-tensioned theme a bit further and decided to see what issues were involved in printing an open structure beam/column system.

For a first pass, I developed this stackable, interlocking beam module.

It was a bear to create with Art of Illusion, but with Netfabb to clean up AoI's nasty STL files I managed, finally, to make it happen.

I did some preliminary partial prints to see what the issues were and discovered that I could either print one segment using the Sleinforge cooling option and wind up many hours later with a column segment that was festooned with strings of ABS ooze OR I could print several in the same time which required much less after-the-print cleanup.

That is when the trouble started.  In the several days prior to this exercise I'd discovered that I could print the column section for the herringbone rack at 32 mm/sec without a serious degradation in print quality.  This made printing these beam segments much less daunting a task.  When I began, however, I ran into a nasty concatenation of disasters that pretty much ruined my printing week.  The first one occurred when I started a print and shortly after was called away for about 45 minutes to help my sister install a new wireless printer she'd bought.

When I returned to the lab I discovered that my Rapman 3 had partially reset whilst printing the raft for the segment leaving the extruder running.  This unfortunate situation burned a small pit in my print table and buried my Kapton tape extruder head in a big blob of molten ABS.  The Kapton tape extruder head had been happily running since October, I believe, without complaint.  Being buried in ABS, however, pretty much put an end to it.

Fortunately, I'd bought several of BitsFromBytes new pre-made, silicone covered extruder heads.  After about an hour swapping out the old, ruined head for the new one I was printing again ...  almost.  There was, of course, the usual running in of a new part.  The new head was about 3 mm shorter than the old one, so I had to go through the whole adjusting for the new print height thingy, complete with printing new trial rafts and the like.

That done, I went back to trying to generate a set of four of the beam segments with Skeinforge.  Months ago, I'd downloaded the latest release, August's.  Skeinforge these days is a busy, overcomplicated piece of software which has far too many bells and whistles hung off of it.  In concept and execution, however, it is a brilliant piece of work.

That said, my column segment exercise pushed right though Skeinforge's performance envelope.  It appears that when you create a BFB file with more than a million lines of gcode in it, that the August version of Skeinforge simply runs out of memory and blows up in the Export routine.  After several false starts I finally got the most recent release of Skeinforge down and sort of working.  The memory problem was gone, but in its place was a total buffet of new bugs relating to both the Multiply option and the Speed option.  The two options appear to interact to produce some really bizarre gcode.

I'd hoped by now to have the new Netfabb gcode generator.  Sadly, the Netfabb people have discovered that the developing of that app was a bit bigger task than they'd originally thought, so the release date got pushed back from 1 February to 1 March.  That left me with either going back to my old copy of Skeinforge and limiting myself to the sorts of objects that it could process or sitting on my thumb for four weeks and hoping that Netfabb's revised release date didn't slip again.

There had been a prior bit of frustration back in November that pushed me into reviving my old Slice and Dice software app from the Tommelise project,  I had actually got pretty far along with that before I was able to get past Skeinforge's nasty learning curve and was able to print acceptably using it.  I went back and looked at that.  Recently, Adrian confirmed that I was on the right track using a brute-force, pixel-oriented analysis instead of the more conventional geometric approach.  Of course, my code is hideously slower than Adrian's, an understandable situation considering that he has been doing this kind of thing for his whole career.  :-)

Still, when I sat down and thought about my situation, I realised that it is in the nature of who I am that if I'm given something I will inevitably test it to its limits.  I always try to make things do things they weren't intended to.  That's just the Scots-Irishman in me, I suppose.  Given that situation, it's very dangerous in a way, to be dependent on equipment and methods that one can't get into and tinker with.  When Skeinforge crashed on me it was suggested that I turn in a problem report on how I crashed it and wait for Enrique to fix it.

Enrique is fast at responding, but I am still too obsessive, now that I am trying to work with post-tensioned, printed structures to happily wait to see if he can easily fix the problem.  Indeed, I find myself not much wanting to even report the problem.

So ...  back to working on Slice and Dice.