Design study for axis columns and stepper motor sleeve

This is a very preliminary design study for a paired column section and stepper motor sleeve of one of the three vertical axes required for a Delta Robot.

This is a segment of the herringtone rack that slots into one of the three slots on the column.

This is all very tentative.  I am trying to learn what fits together with a minimum of fuss.  I've found that if I have shapes in my hands I can see their possibilities and what wants doing with them a lot easier than if I just look at them on a screen.  Hell of a situation for someone who trained as an architect, don'tchaknow.  :-D

Stacking slices to make simple boolean unions

Art of Illusion is a pain in the neck to work with. On the other hand it has the shortest learning curve of any 3D modeling package I've ever encountered and is simple enough for an eight year old to operate.

When I say pain, the primary problem is the boolean ops module. AoI does boolean ops with triangular mesh defined solids. Doing boolean ops on mesh defined solids is a brass bound bastard of a problem. There is a tendency to condemn AoI because its boolean ops module isn't very good. When you go out and start looking at other 3D modeling packages, commercial and open source, you begin to notice that virtually none of them, or all of them for all I know, can import mesh defined solids formats like STL. When you look at how these apps do boolean ops you soon find that the objects you can define have to be very carefully defined out of shape primitives and that these primitives, suitably adjusted by size, orientation and position parameters are what go into the boolean ops module.

That's cheating.

Before I get off into a pointless rant about that, let's get back to the problem I was addressing. AoI is rather simple to write special purpose scripts for. Recently, I wrote one for generating herringbone racks. It was a pain in the neck to design that script, but once it was done it worked perfectly. The rack has a 5 mm flange on either side.

When I set about to design a beam into which that rack could slot, however, I discovered that it would be a very good idea to have some space between where the rack stopped and the beam started. To do that I needed to add a wider, somewhat thicker slab under the rack. I had two choices. I could either go back and rewrite the script {shudder} or I could glue that rack onto the heavier slab using a boolean union op, sort of like this.

While AoI would let me merge the slab and the rack, when I went to do a boolean union op, it simply wouldn't let me.  Not nice.  It was infuriating to be able to look at what I wanted on the AoI display and not be able to turn it into an STL.

That got me to thinking.  Basically, all I wanted to do was put the rack on top of the slab.  If I put the slab through Slice and Dice to create a set of slices and then repeated the game with the rack, keeping the same alignment, it would be a simple matter to just stack the rack slices on top of the slab slices.   Of course, when I set out to do that I unearthed several previously unsuspected bugs in the Slice and Dice code which took me most of Sunday to chase down and fix.

It works now, though.  Slice and Dice can do a simple boolean union between two objects by stacking slices.  I've tested the code and ran it through the whole exercise in the morning.

And there it is.

The slab is 80 x 25 x 2 mm.  The slab and flange are 100% fill.  I printed with 0.1 mm layers using a 0.3 mm extruder at 16 mm/sec.  There was no corner curling or warping at all.  This print is extremely strong.

Time isn't free

Slice and Dice takes up a lot of disk space because it creates and operates on bitmap images, each one of which takes up 22 megabytes, and keeps half a dozen for each slice of a print. That eats up the gigabytes in a hurry.

The problem is that if you have a nasty STL that you've pulled out of Thingiverse, for example, you have to repair the faulted slices. On the recent torso that I printed about 6-7% of the slices were faulted. This usually meant dotting in one or at most two bits on an image to put things right. The problem is that after you've done that on 30-40 slices you're rather hesitant to throw all that work away because you need the space.

Some weeks ago, I discovered that if you zipped bitmaps you could reduce their size by about 95%. This morning I looked into converting over the storage modules to do this using a compression/decompression api. I quickly realised that this kind of job was going to require 3-4 man-days to do. Instead, I went down and bought a two terabyte external disk.

No peel, no warp, no backlash

I got Slice and Dice working well enough to let me do some serious R&D. After a side excursion with partial STLs of hands and naked ladies, I got back to work on the herringbone rack and pinion technology.

My first exercise was to see if I could print single herringbone pinions without having a lot of meltdown problems. Skeinforge had a lot of problems in that regard. In fact, Slice and Dice let me do that.

I printed it pretty much solid for strength and paused it for a couple of minutes midway through the print and let it cool down for a few minutes.  No problems.  This one was printed with 0.25 layers.

Next came the rack.  I decided to use the exercise last night to press the limits of Slice and Dice.  I figured that I ought to be able to print a 250 mm diagonal layout rack.  That let me find a half dozen limits bugs in the S&D code and get them cleared away.  I also decided to see if I could print a useful 0.1 mm layer.

In fact, I could.  Here we are about halfway through the print.

It took about an hour, by the way.

Here it is, complete.

And a closeup of the teeth.

For some reason the extruder is not shutting off between layers.  While that is easy enough to clean up with side cutters, I'll be diving into my code to see if I can sort that out in the next few days.

The pinion gear mates with the rack with no backlash.

I didn't make much of an effort to clean up the pinion which you can see in this outdoor pic.

I've found that the colour rendering is always better outdoors.

Finally, for those of you who haven't a sense of scale looking at the Rapman print table.

My next task will be to figure out how to put the pinion on a  printed, extended shaft so that it can be secured from both sides and mate with the short axled NEMA 17 that will drive it.  Then it will be a matter of integrating my Pololu Allegro 4983 microstepping driver board into my I2C bus and driving the thing from my Microchip 18F4550 uC board.

Printing the naked lady with Slice and Dice

After my experience trying to print the naked lady with Netfabb I decided to have a go at it with Slice and Dice.  I had considerable trouble getting the polymer flow right to bridge the base of the pundendum.  Once I got that right, I set up a shell print with zero infill.

The print went well with the exception of one delamination flaw in the left leg as you can see in this pic.  The lack of support that a light infill would have provided became apparent as I printed up to the top of the breasts and the area around the collar bones where considerable bridging was required.

Aside from that, however, Slice and Dice produced a superior print quality as you can see.

Very little of the z-axis juddering was apparent and the surface quality was superior.  Indeed you could even see the modeling of the body with triangular segments in places.

That was fun.  Now back to work.

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.

Netfabb for Rapman Basic ... FAIL

Okay, now I'm not happy any more.  I designed and used Netfabb to clean up a set of 4, 12-toothed herringbone pinion gears that I have successfully printed many times on the August 2009 release of Skeinforge.  Here is what they look like in Netfabb for Rapman Basic.

Here's what happened when I ran the gcode and "printed" them.

I think it's pretty clear that the raft technology that Netfabb has designed does not work for small, detailed objects.

Printing the naked lady

A few days ago, I got notice from Alexander at Netfabb that I could download a copy of Netfabb

This weekend I've been working with the new Netfabb for Rapman Basic beta. I'd ordered the Pro edition with upgrade to generate gcode for my Rapman 3.0, but it appears that another month or two is needed for that to be ready, so Alexander kindly gave me a copy of Basic to play with.

This weekend I refurbished my Rapman for ABS with a new 9.5 mm acrylic print bed so that I could print ABS and PLA again.

The big problem I had with Basic is that it is set up for a 0.5 mm extruder orifice while I am using a 0.3 mm. Charly at Netfabb kindly showed me how to sort that out this morning, so now I am printing the Pink Panther Lady STL that I downloaded from Thingiverse.

The new calibration that Charly helped me with is working pretty well.

There is a little ripple offset in the print layers that I estimnate at 0.1-0.2 mm that I'm guessing is caused by some sort of truncation error either in the Basic app or in the Rapman firmware.  I hope to get to the bottom of that problem in coming days.  Other than that, the print quality of the Basic beta app is brilliant.

The new raft technique that Netfabb has confected is also brilliant.  They basically print a matrix of candy kiss shaped pillars and then print a flexible net over them that is connected only at the edges of the matrix.  That enables the print, the naked lady in this case, to shrink safely without warping.  It is a REALLY elegant solution to the perennial warping problem that we've all faced for years.

I noticed that the torso started breaking free from the raft webbing when the print was approaching the 100 mm z axis milestone.  The print was working on the connection between the right arm and the shoulder and this started catching when the perimeter was being printed and slowly broke the thighs away from the webbing on top of the pillars.  I put a caliper against the torso to counteract the movement.

That solved the problem for several more print layers.

The torso finally snagged on the print head and moved at a diagonal burying the hot extruder head into the infill and ruining the print.  The failure occurred precisely at 100 mm, raft not included.

Aside from the slight layer juddering {expansion and contraction}mentioned before, the print quality was quite high.

Speak of the Devil...

...and he doth appear. I'd no sooner blogged about my work about Slice and Dice when I got an email from Alexander at Netfabb that said that I could download a temporary copy of Netfabb Basic for Rapman until my professional add-on was ready.

I downloaded it and cranked in the same tea bowl that Vik designed that I am using with Slice and Dice, calibrated it for PLA Red just for fun, selected "5" and tried "Calculate Toolpath".

It promptly crashed calculating layer 34.  I tried the light frame with the same calibrations and it generated a gcode file properly, apparently.

I'm set up to print polypropylene on HDPE so I was going to put things off till my new 3/8 inch acrylic print surfaces arrived.  Again, speak of the Devil, I found that the courier service had left them on the front porch.

I need to log some billable hours and there is a big pile of consulting work that wants doing for a good client, so I probably will get back to this Saturday at the earliest.  :-(

You guys at Netfabb can get the tea bowl that crashed your system at the link to Thingiverse at the beginning of this blog entry.  It looks as likely to give you as much trouble with Netfabb Basic for Rapman as it is giving me with Slice and Dice.

Making Slice and Dice more practical

Continued shipping delays with Netfabb's shipping have given me more time to work on my Slice and Dice alternative app than I had expected. I was able to use Slice and Dice very effectively to turn my light frame STL into printable gcode as you will have seen in my last few blog entries. I then made two decisions which have put me in present limbo.

The first decision had to do with my desire to start working on the problems implicit in printing with polypropylene. Bogdan had developed a lot of know how with polypropylene and characterised it as being a lot like HDPE. Owning some 80 lbs of surplus polypropylene, I decided to have a go.

My first use of it was to try to print my light frame structure. After a few days of that I decided that polypropylene, at least the kind I have, is too rubbery for that kind of application. I then decided to see if I could print something immediately useful, like a bowl, and see if polypropylene was going to be as dishwasher safe as advertised.

I went to Thingiverse and downloaded Vik's beautiful tea bowl. I could have easily designed a bowl, but really liked the look of Vik's. Mind, it wasn't going to look as good in polypropylene as it does in PLA, but never mind. I could throw mine in the dishwasher ... in theory at least.

Vik's tea bowl was a much larger object than my light frame. Hammering the STL through Slice and Dice revealed that the flood routine, which delineates printed and non-printed zones for a slice, did not scale well at all. Replacement of my flood code with a Windows API call for flooding sorted that problem out. Slices that were flooding properly in 8 minutes are now flooding in about 7 seconds.

I am currently working on the fill routine which takes a flooded image and lays out the perimeter and infill roads on the printed areas. That routine, too, isn't scaling well and is taking about 8-9 minutes to process per slice. That means that Vik's bowl will take about 40 hours to lay out the 300-odd slices required for printing. The development of the perimeter roads is taking 99% of the processing time. I am going to have to come up with a new way of doing that process. I have some ideas.

One other little thing that I've found is that the massive amounts of disk space that I am currently using for bitmap image storage can be reduced by more than 98% by the simple expedient of zipping the BMP files using the Windows API and unzipping them only as needed.

Slowly, I make progress while Netfabb hangs fire.

Some crude load tests

Bogdan began to question me about just how much stress these plastic beam modules could deal with.  When he caught on that I was post-tensioning the beams he had no trouble accepting that they'd likely do the job.  Just for fun, though, I went ahead and printed up four modules and assembled them into a 400 mm beam, post tensioned them and ran them through their paces.

I was going to print special end plates, but it's getting late and my day job will be rather intense tomorrow, so I used one of the end plates from the last post-tensioning exercise with the herringbone rack column. For the other end plate I used a strongly designed washer that I printed for another purpose some time ago.

First, I did the same loading as last time, but this time the beam is 30 mm deep instead of 20 but much less heavily built.

No deflection to speak of.  No problem.  That Maglite weighs two pounds and is point loaded at the centre of the beam.

That was nice, but then I decided to get serious about loading, so I broke out one of my ten pound bar bell weights and partially distributed loaded the beam.

A couple of millimetres deflection, but again not much.  I then threw another ten pound bar bell weight on for good measure.

Now you start to see some serious deflection.  Interestingly, the deflection is not because the beam is failing but rather because the lightly designed end plate on the right is beginning to fail.  I replaced that plate with a heavily designed herringbone gear and repeated the exercise.

The deflection is better, but I began to worry that the shear stress at the ends of the beam, which I had planned to handle with purpose designed end plates is ill-applied to the light frame beam itself.

For a final exercise, I point loaded one of the 10 lb weights at the centre of the beam by blocking it with a couple of pieces of scrap ABS.

Guys, post-tensioning is a wonderful technology and very well suited to the scale that we are working at.  Several people have suggested using ABS filament for the tension member.  I think the thing to remember is that conventional wisdom in designing post-tensioned beams is that the tension cable or rod needs to be a LOT stronger in tension that the material it is paired with.  In real life, you see post tensioning done with steel rod or cable and concrete.  Concrete has effectively NO tensile strength.  I personally don't think using ABS filament is going to give satisfactory results as a tension element in such beams.  I use thin studding, lock washers and wing nuts because that is easy to work with and beams can easily be put in compression by hand.

Anyhow, I think that if we want to we can get a lot of the structural steel out of our next generation Reprap machines and greatly improve the printed fraction using this approach.

Printing light structures

A month ago, I designed a light frame structure which I could post tension and use to replace much of the steel in a next generation Reprap printer.

Processing it into gcode with Skeinforge proved to be impossible.  That led me into a meandering sidetrack which had me pushing my old Slice and Dice code into working order after several years of neglect after Netfabb ran late with the release date for their STL to gcode processing module.  Last weekend, I got Slice and Dice working acceptably.

After work yesterday afternoon, I decided to see if I could make my Slice and Dice alpha code successfully generate gcode for a print of that same light structure.  There were a few hiccoughs.  Fortunately, Slice and Dice is purposely designed to let me deal with difficult prints.  I was able to identify problems by doing partial prints and tweak my settings to get past them.

When I got up this morning I finished processing the light structure STL and set my Rapman printer to work on it.  Being a stand-alone 3D printer, it happily worked while I got on with my day job.  Roughly 90-100 minutes later, I had a printed module.

I was quite chuffed with my design.  Clearing the female connectors on the bottom with a 5/32" bit took a matter of a few seconds and let me mate one of my test prints of the top of the module with the whole printed module.  I immediately started printing up a second module.  It finished up a few moments ago.

I think it's pretty obvious where this is going.  I did a short clip of the print underway so you can get an idea of how fast it proceeds.

I am printing a third module now and plan on printing five over the course of the day.  This evening after work, I plan on designing end caps for the assembly so that I can post tension it and then get an idea of how much deflection it exhibits under load for a 500 mm beam.

The lessons I've learned from all this is that if you design light and print vertically, viz, keep the cross-section on the xy print table small, you are going to get what are basically no-warp parts without going through the drama of heated print beds or turkey bags. it's worth thinking about.

In spite of all my warnings...

I'm getting more than a few requests for the code. Please reread the previous blog entry.  If you still want the code for whatever reason, you can download it at...

http://3DReplicators.com/Slice and Dice/Slice and Dice 010310.zip

The code is subject to this modified BSD license.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:


This product includes software developed by Forrest S. Higgs in conjunction with the open source Reprap Project


4. Neither the name of the Reprap Project nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.


THIS SOFTWARE IS PROVIDED BY FORREST HIGGS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REPRAP PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

If you want to modify or upgrade the Slice and Dice app, feel free. You can either let me distribute your upgrades if they fit in with what I am trying to achieve or distribute them yourself. Just give me credit for where you got the original code, okay?