Sunday, March 25, 2007


Java Comms on Win32

Well I feel a little stupid, a little happy, and a little smart. I wanted to figure out what was wrong with the Comms and after using the Linux version, which I knew wouldn't work, I found the right location for it's properties file. After putting back the win32 comms.jar and moving the properties to the lib dir, it worked just fine. Well I'm getting timeouts but without anything connected I expect that.
For my system, as an example if you want to tweak the wiki a bit..
C:\Program Files\Java\j2re1.4.2_13\lib\
C:\Program Files\Java\j2re1.4.2_13\lib\ext\comm.jar

Tuesday, March 20, 2007



I've made things less messy by stacking boards. Testing was getting difficult. I wish I'd planned ahead better, so I could support more than two corners, but two is surprisingly stable.

Also, here is a simplified schematic for my comm unit.

Sunday, March 18, 2007


Biollante Linear Actuator

Here I have a piece of HARDWARE at long last, that actually does something!

The motor is an Eastern Air Devices linear actuator, basically a stepper with threads going all the way through instead of a solid shaft. If the matching threaded rod isn't held still it'll just spin and look silly, so a square shaft matches a square hole in a metal plate bolted to the front to prevent this.

See it on Youtube

That motion is about 7,000 half-steps.

Saturday, March 17, 2007


A testament to Scots-Irishness

I haven't been publishing much this last week, mostly because I've been fighting with the Tommelise firmware to make it do what I want it to do. I've done a lot of hot extruder tests, as you can clearly see.

I've been primarily working on the perimeter/cross-hatching infill misfit problem for the past few days as I'd mentioned earlier. I seem to have cracked that one for now so now I'm going on to get a degree of control over the extrusion rate. As you can see at the top of the foamboard I was running some of the extrusion exercises both too hot and with the extruder head far too close to the board. I'll be working with those parameters and with trying multiple layers over the next few days.

Thursday, March 15, 2007


Biollante Boards and Firmware

On the right you will see the basic design I am using for all my modules except the comm controller. I broke my promise to use two-conductor phone cable to join the modules in their ring, but only a little; I now use four-conductor phone cable!

After a lot of cleaning up, I have also made version 0.1 of the firmware available on my site. It includes code for the stepper controller and comm controller, and hopefully a useful amount of documentation with them; they are licensed under the GNU GPL.

Tuesday, March 13, 2007


Darwin y axis proof of concept

Here is a copy of the Darwin Y axis made in MDF from the proof of concept pdf. I created it on my band saw in 30 min. but I did not drill any holes first so that needs to be done before cutting it out. I think this will work for repstraping Darwin. I would love to try more parts.

Bruce Wattendorf



Oh yeah...

This is all HDPE.


Cumulative overshoots

Turns out that the problem of the cross-hatching being tucked into one corner of the square was due to the fact that the perimeter was made of dozens of tiny extrusion segments while the cross-hatch extrusions were done with two xy coordinates, one at each end of the cross-hatching. Thus overshoots accumulated while I was doing the perimeters that didn't when I was cross-hatching. When I got rid of the overshoots the extrusion looked much better.

I fixed that by editing the .xml file. Now I have to upgrade the firmware to do that on the fly. At the same time I'm going to back up and turn off the extruder between paths.

The foamboard seems to be working quite nicely.


Still printing...

I took a close look at the poplar veneer board that I was using and discovered that it had warped in our dry, winter air. I then cut an 8" x 11" piece of foamboard and taped it down, only to discover that my glass xy working surface is 2 mm lower on the right side (+x) than the left and that foamboard warps, too.

Fortunately, foamboard can be firmly taped down on my tempered float glass working surface and shimmed on the right-hand side to correct for the leveling error.

I then scaled up a slice of a cube .stl file 30x and printed it out to see whether I was getting the perimeter and cross-hatching right. That scaling feature of the Control Panel is really handy for diagnosing problems.

I put the extrusion head a touch too close to the foamboard, in fact about .25 mm into the foamboard. With that in mind let us look at a few features on the photograph.

The perimeter extrusion didn't actually start till a bit into the first side. This was pure sloppiness on my part for not properly priming the Mk 1. There are several commands that I have to send to Tommelise in sequence to have that happen currently and I simply didn't do them. I plan on writing a full priming routine for the Control Panel before too long. Certainly, the commands are there to do it in the firmware. I just haven't so far.

This is a bug in the Control Panel code. I should be turning the extruder off between paths and I'm not. I should also raise the extruder about a half mm between paths, too. I've got the commands to do all that, but again haven't done it yet.

This black bit is actually a scorch mark on the paper surface of the foamboard. While the Mk 1 doesn't reach the legendary Fahrenheit 451 at which point paper bursts into flame at about 400 degrees it is plenty hot enough to scorch paper.

Now here's the real puzzler. The cross-hatching simply isn't filling the slice but instead is tucked into one corner. I've got some sort of scaling problem in the PC-side Slice and Dice or Control Panel code, I think, but so far I haven't been able to understand what is happening to cause that.

Monday, March 12, 2007


Maniacal laughter erupts in the basement...

Finally after running poke through cygwin on Windows XP with my super simple comms interface I was able to conclusively determine successful communication with my stepper controller. Now, I must build more!!!!! Muahahaha...


First Layer Print Hot Run

This was a bit of a hoot! I printed the perimeters of the first layer of the Mk 2 polymer pump at 5x scale to see if things were looking right. I made one big mistake in forgetting to tape the poplar board down. Once the outline was more or less done the extruder began to push the board around on the xy work table leading to all the busy nonsense you see inside the outline.

There's obviously a lot of work to do still, but I'm well and truly started! :-D


Full layer print dry run

I pulled out the first layer from the Mk 2 polymer pump, the bit with RepRap and the green drop logo on it and did a dry run on Tommelise with the extruder turned off. The Control Panel/Tommelise handshaking and data transfer worked without a hiccough. I can now see what I have to do to tweak the firmware to make it responsive to the very short little extrusion segments that the RepRap and teardrop, never mind the perimeters for the holes for the bolts that go through it.

The polymer pump was a nice test because of that distinctive "T" shape it has. You can see that being traced. The cross-hatching was also easy to visualise as the extruder head made its moves. I'm going to upgrade the firmware to account for overshoots internally rather than trying to take the data that the firmware sends back to the PC and have the PC make sense of it. I want the serial comms line loading to be as light as possible. Mind, it hardly occupies any CPU resources on my workstation as it is.

Onward and upward. :-)

Sunday, March 11, 2007



I finally got the handshaking between the Control Panel and Tommelise working right. I had been trying to make it too complicated.

I should be able to do single layer prints now.

What's really nice is that when I look at my Window's Task Manager I see that I'm getting zip CPU loading and can access the rest of my control panel without any problems. That's sweet!


Sorting out quarrels

I spent the weekend trying to get the Tommelise Control Panel and Tommelise to talk to each other. Punching buttons on a PC program that feed control commands to Tommelise a command at a time is one thing. I'm finding that writing a program to automatically feed a control command to Tommelise and be sure not to feed her another one till she's finished with the last one and ready to do another is a different sort of challenge.

Right now I've got the Control Panel and Tommelise exchanging information about half a dozen times before they get out of sync and both start talking at the same time. They then fall into quarreling and the serial link overloads on the PIC chip side.

Needless to say, I didn't get that shot glass printed. I'm currently writing a stronger handshaking protocol than I had before which, I hope, should sort out most of the problems.

Saturday, March 10, 2007


Taking my best shot

I spent a good deal of time today testing Tommelise and making sure that everything was in working order. I shut her down three weeks ago to work on Slice and Dice. I'd had a bit of trouble with her just before I shut her down in that the x-axis had got cranky. It was odd because I could measure the x-axis, which meant that then shaft encoder was operational, but when I tried to run it in concert with the y-axis it was no go. It turned out that one of the solder joints on one of the filament connectors on the shaft encoder had broken. I put that right and it appears that things work properly now.

Scaling on Slice and Dice leaves a bit to be desired, but its conversion of STL files to an XML transfer file that Tommelise's control panel can use to generate print commands is good enough to use. I was going to start trying to print a set of Mk 2 parts till I realised that the aoi files that I have include that cute little RepRap logo. With that there, I need a support structure extruder, something I haven't got just yet. I'll need to remake the Mk 2 parts kit without the RepRap logo and do something about those horizontal mounting holes as well so that I can make it without having to get a support extruder working first. I'm tired of making bits and pieces. I'm ready to do some printing!

In any case, I decided that I'd try to do a shot glass like Vik, Adrian and Ed have done first, that having got to be a bit of an instant tradition. Theirs was too tiny for somebody who spent years in Sweden and who also belonged to a shooting club chock full of ex-Rhodesian Light Infantry types in South Africa. Boy those guys could drink! So, I made up my own in Art of Illusion...

And cranked it out as an STL file, then used Slice and Dice to turn it into XML. It's still a bit small for what you got in South African pubs, but it will do for now.

Now comes the grind of getting Tommelise to print something useful.


Defining a transfer file betwixt Slice and Dice and the Tommelise Control Panel

The RepRap control panel, as it is presently configured, takes as input an STL format file of the object to be printed and converts that on-the-fly into a set of positioning and extrusion instructions for the RepRap 3D printer. I've had a somewhat different concept of how that ought to be done for Tommelise. As I've mentioned before, I've used a different approach to generating the extrusion paths. It's uses a simpler to impliment and what I consider a more robust approach than what Adrian has used for RepRap.

The downside of the approach that I've taken is that it is much, much more of a pig for CPU cycles and RAM than Adrian's app. Throughout my career I've always chosen simpler, less efficient approaches to analysis problems and depended on Moore's Law to make them perform acceptably over time. I've done that simply because I've done a lot of software maintenance for difficult, sassy analysis techniques that are too clever by half. I loathe doing software maintenance possibly because I've had to do it a lot for other people's clever programming. As a result I try to avoid doing clever things with my own computer code just in case I have to also maintain it.

Slice and Dice is now up to an alpha level of development with the majority of the features that I have planned for it working. One of the nice features that I'm putting into Slice and Dice is that the user can grab a part that is to be printed off of a 3D CAD file and convert it "as is" into an STL file. Rotating the grabbed part into an orientation suitable for printing and positioning it on the printing work table can be done completely within Slice and Dice.

I've taken the attitude that Slice and Dice, since my implimentation is much slower that RepRap's is something that shouldn't have to be used every time somebody wants to print a part. That attitude implies that Slice and Dice will produce an interim data transfer file that Tommelise's Control Panel will use. As a result of this approach Tommelise's control panel is a much smaller app that is more akin to a printer driver than a control panel like RepRap employs.

When I gave people a look at my interim data transfer file, Zach Smith noted that it looked like it was going to be a right bastard to parse. Zach works with web apps and is a bit of a data transfer file wizard. When I mentioned to him that I'd written it in an "XML-ish" mode he reasonably asked why I didn't just do it in XML outright then. It was one of those simple notions that isn't at all obvious till somebody like Zach has the wit to voice it. Since then Zach has been kind enough to see me through moving the data transfer file format I'd created over into proper XML.

The data transfer file for Tommelise is just about where it needs to be this morning. You can see a sample of the file structure here. I've taken the first layer of the gearmotor coupling that Adrian designed for the RepRap Mk 2 Thermoplast extruder.

The perimeter paths are still a little too bulky, but they work. What's nice about using the XML file format is that you can use XML parsers to display and edit the contents. That's very handy.

If you are interested in working with Slice and Dice you can download the latest alpha release (version 0.0.4).

Thursday, March 08, 2007


Slice and Dice operational

After a few hours of code cleaning that improved execution speed by a magnitude, last night I ran several full-bore tests of the Slice and Dice routine for Tommelise. The tests created full .tml files for use with the Tommelise Control Panel that drives Tommelise from a Wintel PC.

The tests used .stl files of the gearmotor coupling and the polymer pump taken from the Art of Illusion 3D design specification for the RepRap Thermoplast Extruder Mk2 Thermoplast Extruder.

The .tml file for the gearmotor coupling was about .75 megabytes while the polymer pump's .tml file weighed in at 3.4 megabytes.

The next task is to upgrade Tommelise's Control Panel to read a .tml file and create timed control commands to the 3D printer enabling it to create that object. Since the Control Panel already has a full set of tested commands running the 3D printer this task is not seen to be a major one.

Wednesday, March 07, 2007


Random Repstrap Idea

Previously, Jim posted a blog about how he fabricated the extruder parts by hand. it made me wonder if it would be possible to use a printer to help the process.

simply print your design on a sheet of paper, attach it to the board you intend to cut, the cut where it indicates on the paper. if you glue it on somehow, then you're set!

although with vik's recent success with fabricating extruder head parts... hopefully we can start getting them printed and in the wild ;)


Tuesday, March 06, 2007


Slice and Dice is ready to roll

Slice and Dice is now back to being able to do slices layer by layer for a whole object and create an output file that the Tommelise driver program can work with.

I shifted over the graphics output of Slice and Dice to bitmaps. Bitmaps are a little less sassy to deal with than simply drawing directly onto a form like I had been before. The overall effect has been to make the processes more robust.

I've also pretty much solided up what Slice and Dice's output file format looks like. Here is a copy/paste of one done for a layer of the little gearmotor coupling in Tommelise's Mk 1.0 FDM extruder.

Hmmm... LOL! Well, it appears that my file format looked a little too much like HTML for the blogspot software to be very happy with it. Oh well, if you want to see what the file looks like you can take a peek here.

I've got to collect those cross-hatched "furrows" so that Tommelise goes from the end of one to the beginning of the closest next one instead of all over the show as it does now. That just requires a bit of post-processing, however. I'm not going to try to do that on the fly.

Monday, March 05, 2007


Bitmapped infill routine

Way back in August of last year Adrian noted that...

Forrest has been working on bitmap-based infill algorithms for depositing the build material in layers; these have the advantage of being very robust, but they are a bit memory hungry.

Truer words are rarely spoken. Bitmap-based is a bit of a misnomer, though. What I've got is more of a grid-based approach which mathematically is more or less the same thing. I try to set the grid resolution to the minimum positioning increment length (~0.1 mm currently).

I left off working on Slice and Dice (my name for the routines) not long after August in my rush to get Tommelise running mechanically. About a month ago I had Tommelise effectively running and discovered that I had no software to generate instructions for it to print things, so I had to go back to Slice and Dice.

After many adventures and much frustration, I have the processes that transform an STL slice to something that Tommelise can understand more or less running.

I've also had a few inquiries about getting hands on the code from a few Visual Studio wizards amongst the Reprappers. This evening I got the code to a point where I'm not totally ashamed to let it go.

I've given a few more details than this entry has plus a link to the zip file of the code over at the Tommelise blog. You can get at it here.

Be welcome to take it and play with it as you wish. It is in the public domain and you can make what use of it that you will either as actual code to use or as reference for your own work ... or to just have a good laugh at how nasty my coding is.

I make no representations that it either works or works well.

One thing that I am doing that you may find of interest as an approach is this. Slice and Dice does not attempt to directly control Tommelise. Instead, it creates a file which a much smaller control routine takes and turns into driver instructions for Tommelise. This file contains the places to which the extruder head must go when it is turned on.

The file is in ASCII and can be opened in NotePad or the equivalent. Given how big STL files get I wonder if this is not a better way to store information to drive a 3D printer. It certainly takes a lot of the processing pressure off of the PC driving the printer.

I did it this way because I thought that perhaps it would be nice if the printer driver routine could be clicked onto a file like this and drive the printer in background while the Reprapper could use their PC in foreground for the ordinary sorts of things that people use PC's for. As well, as an approach it might be particularly useful for the $100 laptop types who haven't got a lot of processing power or storage space to work with in the first place.

Anyway, those are the sorts of considerations that I had when I put Slice and Dice together. As Adrian mentioned, bitmap infilling is robust, but it is a bit of a memory pig. Right now Slice and Dice takes 125 meg of RAM to accomodate the Visual Studio development environment with Slice and Dice operating. Given that I have 4 gig on my system, however, I can't say that this is much of a problem for me.

As to using a commercial development system, I'm not too concerned. I know that if the demand gets too great I can always translate my code over to Linux compatable JAVA with this sort of software.

For those of you who want to fiddle with Slice and Dice or just look at the code, be welcome!

Sunday, March 04, 2007


Cause of continuing drama with Slice and Dice found

When you used to take beginning courses in computer programming one of the first things they told you was that if something wasn't working right it was something that you did wrong, not something else.

Over my 40+ years of programming this and that I've found that to be a good rule of thumb. Like all rules of thumb, however, there are instances where it just isn't so. It turns out that the last several weeks of drama I've had trying to get the Slice and Dice routine that I wrote to slice STL descriptions of objects so that Tommelise can print them has been one of those instances.

This morning I was way past my wit's end. You've undoubtedly followed my litany of troubles trying to get Slice and Dice running so that I can start to print meaningful things with Tommelise. I've no doubt that many of you have got the idea that I've either gone softheaded or am too old to be writing code. I've certainly felt that way.

I'd got floodfilling going yesterday and ran some extensive tests on it to see that it was robust. It was immensely more robust than it had been but I still found some problems when I tried to slice the Mk 2's clamp plate. More bugs.

For a change, this time I decided that instead of assuming that everything was all right prior to the flood fill, in exasperation I started at the beginning of the program, or what I took to be the beginning, and started working down to the floodfill routine instead. Bang! Right off the bat I started getting creepy numbers, within 20 lines of code from the beginning of the main analysis loop. After about an hour of that I was on the point of deciding to apply of a slot in an assisted care facility. I gave it one last shot, though, before putting on my bib so that I wouldn't drool on myself and turning on daytime cable TV. Mind, this would be a little difficult since I had cable TV taken out five years ago.

Since there was no more code to analyse, well not completely. There was the little routine that reads the STL file, so I took a look at that. It looked good, so I started checking to see if, perhaps, I was reading in some data in a way that I shouldn't have been.

I opened the coupling's STL file in WordPad and was comparing it with what I was reading when something jumped out at me, not in my code, but in the STL file.

solid "drive-coupling"; Produced by Art of Illusion 2.0, Sun Feb 18 14:59:42 PST 2007
facet normal -0 -1 0
outer loop
vertex 3 -7.5 6
vertex 3 0.407902201579 8
vertex 3 8.5 6

Just looking at it you could see instantly that the triangle lay on the X plane where X = 3. That means that a vector normal to the triangle should be a pure plus or minus X value.

I took a cross product of the first two line segments making up the triangle and got...

facet normal -1 0 0

I then wrote some code to calculate the normal vector from the triangle vertices and used the calculated value and guess what? All the flooding errors went away.

Furthermore, I plugged that patch of code into the Slice and Dice routine dating back to when I started having all this trouble over two weeks and 18 successive versions of the Slice and Dice routine ago and guess what? That old, old Slice and Dice code worked perfectly.

What it works out to is that I've spent over two weeks trying to fix my code when my code was working fine, it was just getting bad data from the STL file that Art of Illusion generated.

Saturday, March 03, 2007


Shameless publicity and cash seeking

All you RepRap fans out there may care to improve the profits of your laundry of choice (and to help RepRap along) by buying a RepRap T-shirt plus a RepRap mug so you can spill coffee down it. Visit

for details. There's also a link from the RepRap pages.

Thursday, March 01, 2007


Floodfill passes acid test in Slice and Dice

I've been battling with the Slice and Dice code that I'd written to develop STL files into extruder trajectories for making things with Tommelise for the past two weeks. In theory, using a grid approach to developing slices is simpler than the method that Adrian has taken. In practice, however, when you try to map a perimeter onto a grid you will often encounter leaks between slightly less than perfectly linked line segments making up a perimeter. My code would get it right about 99.5% of the time. The problem was that you only had to get it wrong once in one layer to make a real mess of things.

How I solved the problem was to map the perimeter onto a bitmap and then floodfill it. After that, it is a simple matter to map the grid onto the bitmap and then check the color of each gridpoint. The hassle with that approach is that it entailed me getting acquainted with the not terribly well-documented differences between VB.NET 2003 in which I last did my last such programming and VB.NET 2005, which I am using now. The differences weren't trivial, let me tell you.

As an acid test I did a test slice on the 79 toothed gear that runs the z-axis on Vik's Zaphod.

It works like a champ! The floodfill routine that I found on the web isn't incredibly fast, but it gets the job done.


Universal Controller Modifications

After building some of the universal controller boards I ran into a few problems with the design. Nothing was a major showstopper, but they were things that make it hard to achieve success on the first try. The problems were:

1. having to solder some components to the component side.
2. some traces were too close together and occasionally bled together.
3. the 'islands' on the component side where the component legs go through can sometimes cause problems (especially if your board gets mis-aligned.)

#1. was easy to solve. for example, with the power connectors where one leg needs to be connected to the copper side and the other needs to be on the component side, you simply solder them both to copper, run a small trace and use a via to bring the component one back up to the right side. most of these have been fixed in this way.

#2. is also pretty easy... i'm just going to make the board bigger. the supplier i use for my boards has a 5"x6" board which works well... except that on the current version of the board there is a decent amount of space not filled. i plan on enlarging this board to fix the dimensions better.

#3. there are islands created where its just a circle of copper. these are where your component legs are supposed to go through, but if there is nothing that needs to be soldered there, its just sitting there doing nothing. sometimes this could potentially cause trouble if you're mis-aligned and the island causes two pins of something to become connected. this can be solved by either finding some flag in kicad to turn it off, or a little bit of post-processing in the gimp / photoshop to remove them. they're very easy to spot.

Labels: , ,

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]