12 Cents Per Gigabyte

640 GB, 7200 RPM, 32 MB cache, 5 year warranty: $75 ($0.12/GB), free shipping.  It’s almost too good to be true.

Still, the best drive for MythTV is Western Digital’s low power series.  I’ve been using the 750GB GP model with MythTV for about a year now and it has been silent and completely reliable the whole time.  It contains an XFS filesystem, which probably helps quite a bit when recording 6 GB/hr (full HD resolution).  The MySQL database that MythTV relies on happens to be on another drive, but I imagine it would be fine to put the database on the same drive.

First RepRap Models

The 3D printer is working and I’ve begun calibrating it.  There’s still a lot of tweaking to do, but now I can finally watch the whole process in action!

All of these are done with ABS.  This is a chronological sequence.  On the left, the extruder nozzle was too high above the bed and the ABS didn’t have any desire to stick to the bed.  I actually printed half a dozen like this until I made up a sticky bed liner.  More on that in a moment…

The second starts to take shape, but there is a big bead of plastic in the top right.  It took me several tries to realize why that was happening.  Can you guess?  It’s kind of funny.

In the Arduino SNAP firmware source code, there’s a constant that defines a stepper motor enable pin for each of the axes.  That pin is not mentioned in the wiki, so I figured it had been added since the creation of the wiki page.  The enable pin is really useful for saving power.  Without the motor enable pin, each axis pulls in 15-20W just to hold its place.  That is especially wasteful on the Z axis, which moves very little during a build.  I don’t like to waste power, so I connected the motor enable pins to my Arduino.

The firmware source code uses the same pin (15) for all three motor enable outputs.  What I didn’t notice is that using the same pin for all three outputs simply can’t work!  The RepRap host software prints the first layer, moves the Z axis, then disables the Z motor while it prints the next layer.  In my wiring, disabling the Z motor actually disabled all of the stepper motors.  D’oh!

I fixed that by disconnecting all the motor enable wires (I imagine there is a pull-up resistor on each board to make the wire optional), then I was finally able to print multiple layers.  On the right side of the photo you can see slow progress toward matching the motor speed with the extruder speed.  The bar is still very curved; I think the main reason for that is the makeshift sticky bed liner.

My makeshift sticky bed liner is a piece of paper lined with double-stick tape and upside down packing tape.  It does stick to the ABS, but it melts and doesn’t stay flat, so the object ends up with a lot of curvature.  The bed liner is the next thing to improve.

I do have a Sanguino, which will solve the pin count problem, but I won’t be able to use it effectively until I have a good breakout board for it.  Thankfully, Zach is working on that.  I could theoretically just solder all the wires, but running 20+ wires off a board with just solder holding them down is asking for trouble.  The wires would break too easily.

Let me also talk about what I did with the heater.  I said earlier that I would add a metal bar as a sort of strain relief to prevent breakage of the nichrome wire.  Here is the heater just before curing the fire cement:

You can see the thin stainless steel bar extending from the brass heater barrel.  The bar has a layer of JB Weld for insulation, then the bare copper leads, then another layer of JB Weld to secure the leads.  At the end of the bar, the leads curve upward and form a socket, where I have plugged in an ordinary connector.  The bar seems to have had the intended effect: even when I get clumsy and bump the heater, the leads are not affected anymore.  I wish I had done this from the start–it might have saved me a month of agonizing over broken heaters!

You can see my thermocouple on the right side of the photo.  It is covered with teflon tape because previous attempts to build the heater destroyed much of the insulation.  I used a thermocouple because I have not found any thermistors designed to handle more than 200 C, and I’ve already determined that extruding ABS reliably requires about 220-240 C.  Fortunately, teflon tape can handle 250 C.  Here is the heater fully mounted:

This heater reaches 220C, as measured by the thermocouple, in 5-10 minutes.  It is limited to 170C if the cooling fan is turned on.  The hottest part of this heater, halfway up the shaft, is about 30C hotter than what the thermocouple measures.  If I allow it to get as hot as possible, the thermocouple can reach 240C, but the acrylic securing the heater begins to melt slightly at that point.  It does not melt when the thermocouple measures 220C.

I learned that if the heater ever falls below about 185C while ABS is inside the barrel, the extruder will not move forward again even if I bring the temperature back up.  I think this is because the small pool of melted plastic just above the barrel cools in a shape that hinders re-melting.  When this happens, I can tell that the extruder is still putting enormous pressure on the filament because the drive screw, which usually carves threads into the filament, ends up grinding an almost smooth surface into the filament.  To deal with this, all I have to do is re-heat the ABS, run the extruder backwards, and cut off the elongated piece that I pull out.  At that point, pushing new filament into the extruder works fine, although the whole process takes 10 minutes or so.

Hasn’t anyone else experienced this?  The software ought to provide an option to maintain the heater temperature even when not building.  I may just put that in the firmware because the firmware is a lot simpler than the host software.

At the moment, I’m using the firmware and host software released in May 2008, with a few modifications:

  • My X axis moves opposite the standard direction.  To move to the home position, the stepper needs to step forward, not backward.  I had to change the firmware to fix this.
  • The temperature measurement calculations simply did not work on the host side.  The firmware showed correct measurements while the host thought the heater was freezing at -17C!  I dug in and found a hack in the Arduino firmware that makes the measured temperature look like a resistance value so the host software can convert the resistance value back into a temperature.  This was apparently done to avoid changing the host software after the conversion from PIC microcontrollers to Arduino.  I ripped out that logic from both the firmware and the host software; now the Arduino simply sends the temperature in C (and expects a temperature in C when controlling the heater).  All is well. 🙂

As the machine builds, there are a lot of unnecessary pauses that cause the extruded filament to curl.  I intend to try out the latest firmware and host software to see if those pauses have been eliminated.  I printed out part of the minimug, but there were so many pauses that it was a curly mess.

Anyway, I’m really close now to a fully functioning RepRap!

RepRap Hardware and Electronics BoM

I just posted the detailed bill of materials for the hardware and electronics in my Rep(St)rap.  Most of the lines have a comment.  The comments and URLs would have made this whole process a lot easier for me, so I hope the spreadsheet helps someone else!

This is the first time I’ve used Google Docs and I must say it’s quite easy to use.  I imported from OpenOffice.  The conversion of OpenOffice.org formulas failed, but it was fairly easy to sort that out cell-by-cell.

I’m sure some people just want to know what the bottom line was.  Well, I paid $555 for the laser cut kit (including shipping), $782 for the hardware and electronics, about $100 for shipping of the hardware and electronics, $100 for 10 pounds of ABS and HDPE spools (including shipping), and $20 for miscellaneous supplies at Ace Hardware.  So $1557, and that’s not including the money I spent on new tools (a drill press, 2 vices, a new hack saw, a lot of drill bits, an M6 tap, an M8 die, etc.) and materials I did not use, broke, or forgot to list in the BoM.

Wow, that’s expensive.  Buying the complete kit from BitsFromBytes probably would have reduced the price.  Still, I prefer this machine and the experience I’ve gained over a big flat panel TV. 🙂

An Abominable, Crazy Idea

What if I were to take a Plone install, delete all of the Zope 2 code (leaving mainly Zope 3 stuff), then mangle the code (including CMF) until Plone works again?

I know I’m foolish for saying this, but my intuition tells me I could actually do it, especially if I got a lot of help from others.  I think it would take 1 to 3 months of full time effort.  I would redesign all sorts of stuff in the process.  The resulting code would not be compatible with any existing site; the necessary migration scripts would take many more months, I think.  But the code would be enough to create new sites from scratch and put them on the web.  The intent would be to make Plone more maintainable.

It would be really crazy… but fun, I think.


I never noticed before that if I open a Konqueror window, point it at an SFTP location, navigate to an image, and right click to open that image using GIMP, that GIMP retrieves from the SFTP URL directly.  When I save that image, GIMP saves it directly to the server.  Sweet!  That means I can edit images on a server without copying them by hand.  I was already doing this with text files, using Kate, but now I can do this with images, too!  This is with GIMP 2.4; I haven’t yet tried 2.6.

Of course, the file dialog used by GIMP is the sickly GTK one, so this functionality of GIMP can only be accessed by opening files from Konqueror or the command line.  The KDE file dialog is really nice and I wish the GTK guys would realize what they’re missing.

The FamilySearch Security Policy Editor and the Zope Component Architecture

Over the past couple of months, I have been working to make it easy for administrators to create and maintain a complex security policy for a giant archive of digital artifacts.  In the process, I think I have found a useful way to configure complex software systems such as Zope 3.

A Security Policy for Dead People

The archive in question stores images, documents, and various other records about dead people.  (Genealogy is mostly about dead people, after all!)  The archive has not yet been deployed, but it will replace an existing simpler system.  Assuming the archive is successful, developers at familysearch.org (my employer) will want to adopt it for their own purposes.  As adoption grows, so will the complexity of the security policy applied to the archive.  Therefore, the security policy must be manageable.  People should not fear the prospect of making changes to the security policy.  Changes in how the system is used should lead to changes in the policy.  If the policy does not evolve with usage, the archive will stagnate to some extent and so will some of the work being done.

Because the requirements are complex, the security policy is also complex.  There are currently six degrees of freedom, meaning that there are six independent variables that affect the outcome of a security policy check.  I don’t know about everyone else, but my quick intuition is typically limited to three dimensions; any more requires a great deal more rational exercise.  Six dimensions is often too much to work with quickly and confidently.

However, I believe the right user interface can optimize that kind of rational exercise.  Following that belief, I created a graphical tool for managing the security policy.  It can answer questions with simple interactions, increasing people’s confidence that they are changing the policy correctly.  I eliminated the need for humans to parse and generate XML, which I think they will find helpful.  But the best part, I think, is I put test-first methodology right before the user’s face.  A screen shot follows.

FamilySearch RBAC Policy Editor

The acronym RBAC in the title stands for Role-Based Access Control.  The six trees in the top left represent the six degrees of freedom; each degree has a grouping hierarchy.  On the right is a report of whether users attempting the selected combination would be granted access.  The reports are updated instantly whenever the user selects a tree node.  The screen shot posted here is showing that according to the policy.xml file in my home directory, users with any role can retrieve any image stream of any published image artifact, regardless of license.  This interface is the place to change that policy.

At the bottom, there are three tabs.  The first tab has a table showing all policy directives.  A directive states that access is to be allowed or denied if the request fits the specified combination.  To change the policy so that people must at least be authenticated before viewing images, the user of this application simply selects the directive shown, clicks the Edit button, chooses a different role, and clicks Ok.

In the status bar is a report of how many tests are passing.  If people use this feature, I expect the application to be quite successful.  The tests tab contains a matrix of tests and test users; each test user has a list of roles.  The cells of the matrix each have a checkbox that shows whether a given test user is expected to be able to do something according to the policy.  If the outcome of the policy does not match the expectation, the cell turns red and the number of passing tests decreases.

RBAC Editor showing tests tab

The report panels on the right feature the ability to show all directives or tests that meet some criteria.  If I want to know why someone’s access is denied when I thought some directive allowed it, I select the conditions of their request, then look on the right to see what the policy says about it.  If it says no directives match, then I select or deselect conditions on the left until I find the directive that needs to change.  If there really is no directive that matches, I add a new directive (and a test!) and verify the change using the report panels again.

The application has other goodies designed to increase users’ confidence, such as fully integrated undo/redo, error and warning highlights instead of cryptic dialog boxes, and “find” fields that filter the rows of the tables.  I expect that this is enough for a security policy administrator.  To make it as friendly as an iPod is not a goal and would even be a disservice for people who are responsible for complex things like a security policy.

A Configuration for Living People

Throughout the process of designing and implementing this, I have kept one thought in my mind: could I use something like this to configure components in the Zope component architecture?  The component architecture solves big, interesting problems, but it also makes the outcome of configuration decisions much less obvious.  If I made an application like this that lets you see and modify the outcome of configuration decisions interactively, would it be useful to the developer community at large?

Boy, would I love to find out.  I started the Zope Jam project some time ago and haven’t done anything with it since, although I thought my initial prototypes looked promising.  I stopped the project because I felt something nagging at me that the design was wrong.  Now I think I see one specific blocker: the whole thing was designed around ZCML.  It appears today that the Zope community strongly supports the component architecture, but not necessarily ZCML.  So the new project would be an interactive configuration browser and it may support more than one way of modifying the configuration.

I still prefer to make it a desktop GUI application (written in Python, rather than Java Swing, which was required for the policy editor), with a variety of low-latency widgets and no access control issues, rather than a browser-based application.  It should run user code directly, so that when the user asks what the outcome of an adapter lookup would be, the GUI’s answer would always be correct.  It should integrate tests of the configuration much like I did with the policy editor.  It should do everything possible to increase the software developer’s confidence in the component architecture.

Let’s Build This

Does anyone else get excited about this?  I love finding ways to make complex things simple.  If I could find a company to fund the development of this, I would work on it full time.  I think it would be a major time saver for any company that is doing significant software development using the Zope component architecture.

There Goes Another Heater Barrel

I put together my fourth heater on Friday and Saturday.  It worked fine for a while; I was able to extrude both HDPE and ABS!  However, after I allowed the plastic to cool in the extruder, I could not get the extruder to drive the plastic again, no matter how hot I melted it.  I had to disassemble the heater to clean it out.  As I was working to remove the ABS, one of the leads attached to the nichrome wire broke.  I don’t have any way to fix those leads, so the fourth heater is lost.  At least I was able to salvage most of the parts.

I now see a pattern in nearly all of the heaters I have built: the nichrome leads have broken every time, and re-heating plastic already in the extruder has never worked and led to major problems.  The re-heated plastic simply refuses to move out the nozzle, no matter how hard the motor pushes; the plastic tends to find alternate paths to exit the heater!

I spent some time thinking about these problems.  I intend to solve the nichrome lead problem by attaching a short metal bar to the heater barrel, the bar extended horizontally, then gluing the leads (bare copper wire) to the bar using JB weld (a hard insulator that can withstand about 310 degrees C).  The extended end of the bar, which should be much cooler than the end attached to the heater, will have a 2 pin socket so I can detach the heater easily.

The problem with re-heated plastic is still a mystery.  The third heater used a PTFE insulator mounted flush against the heater barrel, as specified by the bitsfrombytes diagrams.  With that design, a lot of the plastic exited out the top of the barrel instead of the nozzle, although I can’t remember whether I was using re-heated plastic at the time.  The fourth heater had an 8mm length of the M6 pipe threaded into the PTFE insulator.  Although the fit between the heater and insulator seemed very tight, the ABS still found a way to exit out the top and made a nasty hard shell covering the threads.  I now realize that the M6 tap I used was designed for tapping hard materials like metal, not soft PTFE; an M6 tap designed for soft material would have a slightly smaller diameter.  Next time, I will make my own tap using brass or just force an M6 screw into the PTFE.

By the way, I have begun putting together a BoM for the hardware I actually used.  Tres expressed interest in it and I imagine others will be interested, especially now that Vik has provided a way to buy the laser cut parts for around $400, a lot less than what I paid.  Excellent work, Vik!

Doug Wright on Throwing Away Your Vote

I listened to the Doug Wright Show this morning.  He was adamant that all voters should vote for a “viable” candidate rather than the candidate they believe to be best fit for office.  He claimed it is more important than ever to vote strategically in the upcoming election.

No matter how I vote (and how all of Doug’s listeners vote), this state will vote for McCain, and only divine intervention would stop that.  This state is extremely (and I believe excessively) loyal to the republican party.  So why shouldn’t I vote for the person I believe should win?  No matter how I vote, I can’t change my state’s electoral vote.  All I can do with my vote for president is try to reduce my state’s excessive loyalty to the republican party.

Unabashed Dorky Enthusiasm about Willowrise

It turns out I am supposed to unleash my inner dork.  In other words, I should write about my passion.

I am passionate about building a family business.  That’s what Willowrise is.  We have plenty of skills and talent, but we’re still working out how to present our skills to the world.  We’re certainly not a retail shop, yet that’s what our current home page makes us out to be.  We’ll probably always have an online retail shop, but that should not be our main focus.

As a business, we want to build on each other’s talents and create expressive things.  Much of our business so far has been independent of each other, even though we are a tightly knit family and we work together well.  We are looking for projects that exercise our combined talents.  Some ideas:

  • Instructional design (could be a perfect fit)
  • Outdoor games (not video games–we want to encourage people to play outside!)
  • Hmm, we need more ideas!

We have created and sold many great pieces of art, the excellent Dayspring CD, some cool web sites, some software, and even some hand-made flutes, but these have mostly been individual efforts.  Working together is what we really want to do.

RelStorage Test Plan

Before I release RelStorage 1.1, I believe I should set up a complete test environment.  The test environment will test different versions of Python, ZODB, the supported databases, and the supported database adapters.

I started by installing buildbot, hoping it would solve most of the problem for me.  However, I wanted a builder that would check out two things, ZODB and RelStorage, and install them both; there is no obvious way to do that in buildbot.  So I uninstalled buildbot and decided to write scripts instead.  Maybe I’ll figure out how to make buildbot run my scripts later.

Using Linux-VServer, which I already have set up, I will set up 3 new virtual servers and name them after birds that honk when you annoy them.  “goose1” will be 32 bit Debian Etch with Python 2.4, PostgreSQL 8.1, MySQL, Oracle 10g XE, and cx_Oracle 4.x.  “goose2” will be 32 bit Debian Lenny with Python 2.5, PostgreSQL 8.3, MySQL, Oracle 10g XE, and pre-release cx_Oracle 5.  “goose3” will be 64 bit Debian Lenny with Python 2.5, PostgreSQL 8.3, and MySQL.  Each of the servers will test several combinations of RelStorage checkouts (the trunk, the 1.0 branch, and the 1.1 branch) and ZODB checkouts (the 3.7 and 3.8 branches at least) with all of the installed databases.

This will not test all possible combinations, but should be enough to catch a lot of problems early.  Combinations that I would classify as unimportant at this time include 64 bit Python 2.4 (since Python 2.5 supports 64 bit much better) and Oracle on a 64 bit host (since 10g XE only comes in 32 bit).