Processing gcode instructions with the Rapman firmware

After running a variety of speed tests with the Rapman, I gained enough data to estimate the processing time for two kinds of gcode statement.  The G1 statement processes in the Rapman 3.1 firmware at a rate of 17 msec/instruction.  M108 instructions process at a rate of 19 msec/instruction.

Interestingly, the rate for the M108 instruction is actually significantly longer than for the G1.  Given the floating point instructions necessary to interpret a G1 instruction this seems very odd.  It would seem that much more time is spent reading off of the SD card than processing the information on a line of code.  Either that or carrying out a M108 instruction in the Rapman firmware is more complicated that it would appear at first glance.

As a practical matter what this means is that if one wants to print a layer with 0.1 mm print road lengths you are looking at a maximum print speed of around 5.8 mm/sec.  A print speed along a long road component axis of 16 mm/sec would imply that your average road segment would be no less than 0.3 mm.

Further tests

I did a very careful, new series of speed tests using F960 (16 mm/sec) over a much longer diagonal baseline, viz, 1.7 meters, with the extruder running.

Here's what I found...

Step (mm)    Seconds (s)    Velocity (mm/sec)

    0.1                214                   5.77
    0.2                110                 15.40
    0.3                121                 14.14
    0.4                  80                  21.21
    0.5                  80                  21.21

Note that...

21.21 mm/sec ~ 16 mm/sec x 2^0.5

...which is about what you would expect for firmware that didn't correct for the angle of the print road.

As you can see, the break comes between gcode distances 0.3 and 0.4 mm and is quite abrupt. This means that the vectorization routine for Slice and Dice can be quite crude and work well with Rapman.

What does F960 really mean?

The vectorizer in Slice and Dice is pretty inefficient. With certain slopes and curved surfaces I'd noticed that the print head velocity could drop by as much as 25% down from 16 mm/sec to 12 mm/sec. I'd spent the last weeks working on improving my vectorizer when it occurred to me that I really didn't know how much improvement I needed to make on it.

To sort that out, I did a series of test runs where I moved the inactive print head from x = -75 mm to x = 75 mm using different steps with the nominal head speed set to 16 mm/sec (F960).  Here are the very strange results that I got.

     Step (mm)     Seconds (s)     Velocity (mm/sec)

         0.1               25                         6
         0.5                 5                       30
         1.0                 3                       50
       10.0                 2                       75
     150.0                 2                       75


As an example of the gcode I used...


G90
G21
M103
M105
M104 S0
G1 X-75.00 Y0.0 Z20.0 F960
G1 X-74.90 Y0.0 Z20.0 F960
G1 X-74.80 Y0.0 Z20.0 F960
....
G1 X74.70 Y0.0 Z20.0 F960
G1 X74.80 Y0.0 Z20.0 F960
G1 X74.90 Y0.0 Z20.0 F960
G1 X75.00 Y0.0 Z20.0 F960
M103
M104 S0
M103

I did further tests and discovered that unless the extruder is running the extruder head speed defaults to 75 mm/sec.  When it is running F960 seems to be the speed of traverse of the longest dimension {xy} of the print road.

Specifically, I ran a 150 mm diagonal and discovered that F960 {16 mm/sec} clocks in at about 23 mm/sec.  when you divide 23/2^.5 you get right at 16 mm/sec which means that the traverse speed for the x and y axes, which with a diagonal are equal, is 16 mm/sec.

BTW,  I've started getting an SD Error2 report at the end of one of these test runs.  I'm not at all sure what that is all about.

Bookkeeping and janitorial duties

There isn't much that is flashy to report at this time. A lot of my time in the past few days has been focussed on a telepresence 'bot project I have intended to design and build for years that the Rapman finally lets me design and print parts for. Oddly, though, getting the basic software modules that will control the 'bot all working together looks to be far harder than printing and building the 'bot itself. I guess that having worked on Reprap for five years now makes me a lot less intimidated by hardware tasks than previously.

Last week, I discovered that Slice and Dice's vectorization routine, which converts pixel defined boundaries to print areas into vectors usable in gcode, wasn't particularly nice. It was not reducing the boundary definitions nearly as much as it ought to have been. What that means as a practical matter is that it generates a lot more gcode than it ought describing very sort little print roads of a few tenths of a mm. Rapman is not designed to deal very efficiently with that kind of gcode and what happens is that the print speed drops well below the nominal rate set with the "F" specification. That not only wastes time but also puts more plastic on the print than it needs to have in areas where the perimeter curves. THAT makes for poor print quality.

I got to the bottom of that problem over the weekend.

As I set up for testing some new approaches to vectorization, I remembered that shifting from BMP to PNG reduced the disk requirements for a print project dramatically. I have plenty of disk space, but the reduction in disk requirements led me to redesign the files handling for Slice and Dice so that one can readily process and work with more than one print project at a time. That job holds no challenges as such, but is merely a bit of tedious restructuring files handling routines and testing to make sure that they all work. I've got that about two-thirds done.

Thus, slowly but surely Slice and Dice begins to look like very preliminary beta code.

Collapsing the hard disk requirements of Slice and Dice

I managed this by the simple expedient, suggested by my son Adriaan, of replacing the BMP format slice image files with the Portable Network Graphics (PNG) format which uses a lossless data compression scheme.  This reduced my slice image files in size from 16-22 Mbytes per slice to 80-100 Kbytes.

Delta 'bot Axis

It's one thing to design and print plastic parts that have to mate with steel rods. As I am finding it is quite another to design plastic parts that have to mate with other printed plastic parts. During the last week in my spare time I proved out a design for a hexagonal column which I think might accommodate a herringbone rack and a sleeve seating a pinion gear, stepper motor and two guide plates.


Heretofore, I have been butt seating the column sections and then post-tensioning them. While that was okay for demonstrating the design approach, worries about creep said that I needed to have a male/female attachment technology so that I could fit sections of the column together and avoid having them do a lateral creep out of alignment. That proved to be considerably more difficult than I imagined.


This last weekend, I decided to take a different approach and instead of doing a conventional slice and dice of an STL, I decided instead to work with the print roads of my thin-walled column instead. What I did is a radial 45 degree overhang inside the column onto which I printed the male insert. I think it is worth mentioning how I achieved that.


The column was achieved for most of it's length with three concentric print roads of 0.6 mm width. What I needed to do was to build a ledge inside the column. When I began the ledge I widened the innermost print road to 0.8 mm. On the next layer I replaced the 0.8 print road with two 0.6 print roads. This process left me a 0.2 mm miniledge onto which the new innermost print road could adhere. I repeated this process until I had a ledge wide enough to print the male insert onto.


You can see the insert successfully executed here.

I would like to be able to say that that was all an easy exercise. It wasn't.  I did exactly thirty text prints like the one you see before I was satisfied with the seating of the guide strips, herringbone rack and the male/female column connector system.  I also had to chase several heretofore unsuspected bugs in Slice and Dice AND extend the coding somewhat.  All the same, it's done and works so far.


At that point, I decided to see how tall a monolithic column section I could print.  It appears that Rapman three can handle about 225 mm in the z-axis.  I designed a 200 mm column with a 4 mm male connector and am printing it at present.

It is 2120 and I am up to about 50 mm.  I'm doing a 0.25 mm layer every 45 seconds, so I expect to be finished at about 0500 tomorrow morning.


With such a large print I began to encounter xy and z faults.  The xy faults were annoying, but the z faults tended to plunge the hot extruder head into the print.  Upgrading the Rapman firmware to 2.0.8 got rid of the z faults but the xy faults remained.


I reduced the column test print to 55 mm, relocated the Rapman further away from my PC on a table by itself away from the cold window and switched ABS to HDPE because the acrid fumes were getting to be too much when I wasn't able to open the windows.

A thorough cleaning of the extruder with compressed air was also undertaken.  After a few test prints I got the flow rate sorted out for HDPE and was able to successfully print a 55 mm column section in HDPE.

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?

Slice and Dice 0.1

Last month, Adrian incorporated some ideas for using pixel maps that I'd used years ago with Tommelise 1.0 into what I understand is his most current version of the Reprap host software. At the time I was happy that my approach had proved to be of use to him.  I was, however, happily using Skeinforge with my Rapman printer at that time and didn't think too much about it.

Enrique's Skeinforge is a brilliant piece of software for non-mainstream Reprap printers like my Rapman.  As is my wont, however, I tend to test the envelope with just about any piece of hardware or software that I undertake to use.  The problem with testing the envelope is that too often you push right through it.  That happened to me when I started trying to print light, open structures like this.

Enrique invariably handles error notifications within a day or two.  I frankly don't know how he manages.  It must require superhuman capabilities for one person to manage that for so many users.  What I was trying to do, however, wasn't eliciting what could be termed an error as such.  The individual slices for what I wanted to print were quite small.  As a practical matter, what that means is that is that the layers tend to overheat from the extruder tip being over them too long on average.  Let that go on long enough and you wind up with a print that looks like a melted candle.

Skeinforge has a "cooling option".  What it does is time how long you are spending printing a layer and if it falls below your set point it orbits the extruder tip around the print till it has a chance to cool off.  Thanks to the tendency of extruder tips to dribble ever so slightly, if you use this option your print becomes wrapped in what looks like plastic cotton candy.  It is a bear to clean parts wrapped up like this.  The other way that I developed when printing small pinion gears was simply to print 6-8 of the same thing at once, something that Skeinforge lets you do very easily.  While that is very handy if you need a lot of a thing, if you're just trying to develop a part you take 6-8 times longer to print your part and find the errors in the design.  With ABS costing $10/lb using Skeinforge's multiply option is not a very practical as a cooling method.

I finally came to the conclusion that Skeinforge, as it presently is written, wasn't going to take me where I wanted to go.  I had ordered a copy of the new Netfabb programme to do the same thing, then learned that their product rollout was going to be at least a month late {1 March}.

With several weeks of time on my hands, I decided to dust off my old Slice and Dice software and see if I could knock it into shape to do what I wanted.  Three weeks later, it's running.

Let me tell you from the beginning that Slice and Dice 0.1 is most definitely NOT an alternative to Skeinforge, Netfabb or the Reprap Host software.  If you are thinking that, forget it.  Now I'm not trying to keep anything proprietary.  If you want the source, I will give it to you under a BSD-type license which lets you do pretty much anything you want with it.  Indeed, I've handed out several copies already to a few reprappers who wanted a look at this or that bit of the code.

Before you decide you want it anyway, however, here are some facts about it that you should be aware of.

• It is written in Visual Basic .NET {the free Express 2008 edition}
• It is Windows specific
• It is NOT beta code.  I'd have a hard time calling it alpha code at this point.
• It is set up to handle only one print object at a time.
• It keeps multiple bitmap images {BMP} of each slice.  These are 250x250 mm with a 0.1 mm resolution {figure 22.5 megabytes per image.  All the processing is done on images that you can look at.  What that means is that a decent design is going to generate many, many gigabytes of images.  I don't care since I have a 1 Terabyte external disk committed to the programme.
• I will NOT provide support for Slice and Dice 0.1.  If you take it you're on your own.  I admire what Enrique is doing but do not envy his situation and most definitely do NOT mean to in any way compete with Skeinforge and Enrique or Reprap Host and Adrian or the good Germans who are fielding Netfabb.  I'm not young and life's too, too short.

I've put Slice and Dice 0.1 together for one specific reason.  That is to let me try out off-the-wall 3D printing ideas that often times will go beyond the capabilities of ordinary software.  Most importantly, its a piece of software that I've written and can easily dive into myself and fiddle with to make it do new things without having to report problems to and make requests from others.  I figure it will save me a lot of development time by shortening the development cycle.  It for sure will keep me from making a pest of myself making requests for changes in their code to Adrian and Enrique.  That should be good for everybody's nerves.