Saturday, February 06, 2010

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.


21 comments:

Dave said...

Hi, Forrest:

About 1 year ago, the reprap hardware itself was the biggest barrier to smooth printing: pretty much nobody had an extruder that would run more than a couple weeks without a rebuild. Back then the software was a problem but not the bottleneck

Now, though, it appears that the need for a good piece of software designed for this use case is one of the biggest problems.

My perspective is somewhat different from most: I think that, though STL is the defacto standard, what's really needed is a tool that accepts STEP solids. CoCreate and SolidWorks ( commercial cad programs can create this format). Yes, AOL cannot create it, and I'm sure i'll get flamed for suggested a solution that is not 100% FLOSS. My counter would be that creating a tool that uses STEP files would create a need for a FLOSS tool that creates the format.

STEP is a good solid format that will elminate most perofrmance problems, because it doesnt approximate a solid with triangles. Yes, its harder to parse STEP than STL, but what you get is worth it: you get arcs instead of little lines. You get precision, and no screwed up triangles.

A few months back, I was able to successfully use python occ ( a python binding for OpenCascade ) to successfully import a STEP file, slice it into layers, and create offset toolpaths. As a bonus you get a full featured CAD viewer !

I've had no time lately due to kids-- but if you'd like i'd be happy to send you a copy. If you are serious about getting a decent piece of software going, i think opencascade and pythonocc is a fantastic start.

python occ is under active development:

http://www.pythonocc.org/blog/

You can get the files here, where i posted it orgininally for RepRappers..

http://forums.reprap.org/read.php?12,20013,23357

If you are interested in going this route let me know. I believe using STEP solids could actually put the reprap communitity ahead of the commerical community, who still instists on using a completely broken solid format.

Dave said...

also here is a screenshot of it in action slicing a test piece.

no triangulation-- 100% perfect slices and no approximated arcs

it can handle STL too by using opencascades STL import and mesh fixing.

http://dev.forums.reprap.org/file.php?12,file=1549,filename=OccSlicer.jpeg

Forrest Higgs said...

I've been following the somewhat desultory push for a shift to a STEP or similar approach for some time in the Reprap core team. In fact, I downloaded and was looking at OpenCascade a few days ago and worked my way through a few of the tutorials.

I got the distinct impression that the boolean ops module in OpenCascade depended completely on the objects being operated on being in STEP format or similar. I DIDN'T get the impression that OpenCascade could do boolean ops on triangle mesh representations of objects.

Let me pose a hypothetical scenario. Suppose I had an object and scanned it, creating a point cloud. Typically, point clouds are turned into STL or OBJ formats.

If I imported those objects into OpenCascade, could I do boolean ops on them?

Dave said...

OpenCascade's strength is its solid kernel. IE, it understand nurbs, arcs, lines, faces, edges, etc. It also includes a parametric module for definition of solids the way its done in solidworks.

In fact, in OpenCascade, you would import a step( or iges or otehr format) model, and then it is represented internally in OC's internal format ( a collection of solids, surfaces, edges, and faces). You can do

While a solid is inside OCC, it 'knows' its properties as a full-fledged solid. Then, when you export it to STL, etc, you lose all that.

In OpenCascade, you can do boolean operations on anything that you've been able to define as a solid. You can, for example, import STL ( which creates a meshed surface ) and then define a solid from it. Once you have a solid, you can subtract/union other solids, etc.

You could infact use OCC to go from a pointcloud to a solid, but it would be non-trivial. You would do roughly these steps:

1. load all the points
2. loop through the points, adding them to a surface ( or multiple surfaces )-- this would be tricky
3. join the surfaces together to enclose a space
4. promote it to a solid.

if the surfaces compose an OCC solid, then yes it is at that point a first-class citizen and you can boolean it with other solids-- either ones you create using boolean operations or those you have imported.

Forrest Higgs said...

I'm not worried about going from a point cloud to an STL. I've done that. What I'm curious about is the ability of OpenCascade to convert STLs, especially imperfect ones, into usable STEP descriptions.

While I've been through a couple of tutorials, I have yet to run into how one imports and works with STLs. Can you give me some idea of where to look to learn how to do that?

Dave said...

Oh just one other thought, you might appreciate the details of how my OccSlicer works, because its working code you could try on your objects:

(1) load STL to create a surface mesh. ( you can also load STEP )
(2) fix the mesh using OCC tools to plug holes
(3) promote the mesh to a solid
(4) create a series of planes with various z levels
(5) for each z-plane, create a solid box ( more precisely a solid-halfspace )
(6) compute the boolean subtraction between the halfsace and the solid object, resulting in exposing the slice i want
(7) find the top face of the resulting solid
(8) export the edges ( which are either curves or lines ) of that face-- this is the slice

Because OCC is C++ code and because these operations are done in an optimized kernel, the above steps can compute slices much much faster than skienforge, even though its doing fancy boolean solid operations at each slice.

Forrest Higgs said...

LOL! Hell, that's no big trick. My pixel slicing approach code written in Visual Basic is considerably faster than Skeinforge even when I run it in interpretative mode. :-)

Mine also does a pretty nice job with considerably less than perfect STLs, too. :-)

That said, my goals have always been robustness and ease of code maintenance. For the past thirty years I've always safely bet that Moore's law will catch my code up within a very few years insofar as efficiency is concerned. :-)

Dave said...

Hi, Forrest:

Can you PM me and i'll email you a more detailed set of source that should get you going....

Dave said...

Here's the OCC code required to read either STP, STL, or IGES into a 'shape', which can be then used to manipulate:

def LoadFile(self,filename):
extension = os.path.basename(filename).split(".").pop().lower()
start_time = time.time()
if extension =="step" or extension == "stp":
stepReader = STEPControl_Reader()
stepReader.ReadFile(str(filename))
numTranslated = stepReader.TransferRoots()
shape = stepReader.OneShape()
elif extension == "stl":
shape = TopoDS_Shape()
stl_reader = StlAPI_Reader()
stl_reader.Read(shape,str(filename))
elif extension =="iges" or extension =="igs":
i = IGESControl_Controller()
i.Init()
iges_reader = IGESControl_Reader()
iges_reader.ReadFile(str(filename))
iges_reader.TransferRoots()
shape = iges_reader.OneShape()
else:
return True
self.canva._3dDisplay.DisplayShape(shape)

Dave said...

also check out OccSlicer, which is available here, for functioning ( python code ):

http://home.bluedirt.org/OccSlicer/

It will also export an svg file that skeinforge can process: Enrique and I collaborated on the format

Forrest Higgs said...

Dave: With all due respect, I am a bit averse to getting tangled up in yet another programming language, viz, Python and another chunk of code the mechanics of which I'm not even foggily acquainted with. Mind, I can understand your excitement about what you have achieved so far. It looks good.

That said, the learning curve hurdle to my taking an active part in its development is a bit high, considering the small amount of time that I have in my declining years.

As you are aware, Skeinforge is a Python programme. If I had the skill set and the time, I'd probably be digging around in Enrique's code trying to make it do what I need to print the designs I'm working on.

I hate to be discouraging, but I have to be a bit jealous with my time these days. :-(

Dave said...

I understand-- good luck...

Forrest Higgs said...

Thanks, I really appreciate the understanding and good wishes.

paul said...

Here's a probably-stupid question:

If you can work around the issue of head clearance, does it make any sense (mechanically or in software) to treat (parts of) structures like this as vectors-with thickness rather than slices? Could a reprap successfully build something like this as a series of posts and beams, with movements in x, y and z (or x and z / y and z) rather than x-y movement followed by a z step?

If you could do it, would you want to bother? It seems to me the resulting structure might be stronger or lighter, but I'm probably wrong.

Forrest Higgs said...

Paul:

I've thought of that on and off for several years now. The problem with the approach, as I see it, is that it assumes that the thread that comes out of the extruder head cools pretty much instantly. If it doesn't, it sags.

If it does that, how do you get the thread to adhere to prior structure?

Have I missed something here?

paul said...

Well, we know that (under some conditions) we can bridge fairly large horizontal gaps just by letting the first few layers sag and subsequent layers pile up on top of them. And there's the whole overhang thing that suggests a fair amount of leeway. But the only way to actually find out would be for some poor fool (yeah sure, right after my stepper motors arrive) to actually try it and see what kinds of Z-angled printing could work.

I would expect that this wouldn't work in the general case, but then you don't need it to work in the general case. A few simple structural components might be all you need. My thought (probably wrong) is something that looks like open-web joist, only with vertical posts to support the angled parts at the extreme of their distance from the base flange. A lot would depend on how wide the spacing between posts had to be to allow (part of) the head to clear.

Forrest Higgs said...

Paul:

You might find this interesting.

http://blog.reprap.org/2006/11/faster-cheaper-better.html

paul said...

Cool! I can't begin to imagine how you could vectorize something like that, but I bet you could...

Anton said...

A thought just occurred to me in regards to the strength of the columns in view of the printing direction.

I realize that post tensioning will still be needed but couldn't the strength of the individual segments be strengthened by dipping the segment in a mild acetone or similar solvent solution?

Minor imperfections in the print might be mitigated by the fusing performed by the solvent?

Forrest Higgs said...

Possibly. Heretofore, the acetone treatment for ABS has been used more to enhance the cosmetic appearance of printed objects. I wasn't aware that it could also enhance strength. Could you tell us a bit more about this?

Anton said...

Well, it is just a thought, but it would seem to me that if during the extrusion process imperfections were made between individual vertical slices making up the rod, an acetone treatment would allow ABS to flow with acetone into minor irregularities. Sort of like dipping a candle into molten wax allows the growing of a layer or completely resolving the object, depending on how long time it remains in the hot wax.