The Future Belongs to the Creators ™

Wikihouse: Floor Slice assembly

We spent about an hour assembling the Wikihouse floor slice we are testing. All is well and we will continue with a bigger build. This slice test was really just half of a floor section. We only attached a single floor panel so the framework underneath is exposed to show visitors.

Assembly was quick and we only had a few parts reversed.

What Did We Learn?

  1. A set of assembly instructions would be nice. Otherwise, assemble the first section perfectly and use it as the standard to build to.

  2. In creating our cut files, we grabbed elements from the SketchUp Maker Faire Pavilion plans. Now that we’ve assembled them, there are more unique parts than we first noticed. For example, there are 3 kinds of “feet”, the piece that usually joins the floor and ceiling while lifting the structure off the ground. There is a Deck Foot where the floor has no walls. There is an Exterior Foot that has a wall. Finally, there is a Adjacent Structure Foot that has an extended tab to join with another structure.

  3. There are 2 types of floor panels. A Deck Floor Panel is longer than an Interior Floor Panel.

  4. Since our test slice is a standalone structure, we should have cut 8 Connector Caps that partner with our Span:XX’s which provide the structure between the main fins. Without the caps, the gap remains open and de-stabilizes the fins. For a workaround, we used Spike Pegs to shim the beams in place until we cut proper Caps.

  5. We need 2 C-Peg Locks. They join the main beams together at the S-Joint.

  6. Some error in our export or conversion created a small glitch on one slot in our Span:AA and Span:BB parts. If we used both Floor Panels, we’d need to cut error out with a jigsaw.

  7. We are considering shoring up the middle of the structure. From all the Wikihouse models we looked at, it seems they are missing a span in the middle between the main beams right where the two floor panels butt together. We call this a Span:YY and it slides over the main beams. At the same spot, we will also be adding a foot to the Span:AA and Span:BB to add more lateral support to the main beams. We may alter the Interior Floor Panel the accept a slot or design a new Span:YY that would accept a perpendicular piece to sit below and along the plywood seam in the Floor Panel.

[gallery ids=”795,797,799,809,807,805,803,801,811,813,815,817,819”]

Wikihouse: Cutting Parts for the Floor Slice

We have all the parts cut. Now we are removing the tabs to free them from the material and quickly hitting their edges with a sander.

Since we machined them with a square-nosed upcut spiral end mill, we are getting tear out when the bit travels across the grain of the wood. The easy fix for this is switching to a compression spiral - which is a much more expensive bit (2-3x cost…$66).

Wikihouse Parts

Once all the parts are finished, the next step is assembly.

Wikihouse: Building a Floor Slice

Now that we have passed the Wikihouse Calibration Test we are ready to cut real pieces.

We decided to use the SketchUp Makerfaire Pavilion since it was actually cut and assembled. There is proof on the SketchUp Blog.

So far our Wikihouse process goes like this:

  1. Download SketchUp Model
  2. Export SVG using the Wikihouse Plugin
  3. Take apart model in SketchUp and confirm all parts are in SVG
  4. Figure out why parts are missing (Ex: The posted pavilion model has a copy and paste error - the fins under the floor panels have faulty slots so the plugin can’t export them…)
  5. Trick plugin into exporting missing parts6. Import SVG into Illustrator and save. Check measurement of plywood panel in model to ensure correct scale in VCarve.
  6. Import Illustrator file into VCarve Pro.8. Use VCarve to nest parts - this test fit on 6 sheets of plywood
  7. Setup Toolpaths and save Cut files for each Sheet.

Here are the previews of our sheets:

Sheet 0 - Floor Panel

Sheet 1 - 2xSpanAA 2xSpanBB 1xSpanXX

Sheet 2 - 3xFootA 1xSpanXX

Sheet3 - 1xFootA 2xFootB 1xSpanYY

Sheet4 - 2xFootB 2xSpanXX 1xSpanYY

Yesterday we dropped by Roddis Lumber and put in an order for some nice Maple D-3 48x96 3/4” plywood. They delivered it today so our next step it to cut.

Wikihouse Build - Calibration Test v1.1 Final Assembly

After reworking the Wikihouse plugin SVG export in VCarve, the cut files were recreated. The main changes in this version were:

  1. Used normal fillets instead of dog bones on the internal corners. In the next project, we will skip adding fillets by hand and confirm that VCarve will handle the toolpaths itself.

  2. Cut the missing c-shaped peg (Added some extra pegs just in case)

  3. Added part labels - went with an abstract grid instead of plain lettering.

  4. Set an offset allowance (-0.01”) on slot toolpaths so the parts fit without sanding

The resulting preview of the toolpaths.

[caption id=”attachment_699” align=”alignnone” width=”300”]WikiHouse CalibrationTest v1.1 Updated toolpaths[/caption]

After recutting the parts, removing the tabs to free them from the material, and assembling them, we learned some more.

  1. When using the negative offset allowance on an inside toolpath means that 0.01” is added to each side of a rectangle. So the actual width of the rectangle is increased by 0.02”. After this assembly we could increase the offset to 0.03” and still have good part fit. In our first test, we had to sand parts so they could fit together. This build went easier but parts still needed to be tapped into place with a deadblow mallet.

  2. The part labels were cut at a depth of 0.07” to be deep enough to be visible. It would look better if the depth was less than the thickness of the first ply. When cutting through the first layer of ply which is usually a higher quality, the second layer may have voids, discoloration, or adhesive that are exposed.

[caption id=”attachment_701” align=”alignnone” width=”300”]Wikihouse Calibration Test - v1.1 - Final Assembly2 Wikihouse Calibration Test - v1.1 - Final Assembly[/caption]

Wikihouse Build - Calibration Test - Second Attempt

After building the Wikihouse Calibration Test, we learned that we were missing a part. There is a C-Shaped peg that locks two of the beams together.

Once we assembled the test parts, we tried to use a different kind of peg that didn’t fit correctly. Going back to SketchUp, we started deleting objects until the part we needed was exposed. We then reviewed the SVG we generated from the Wikihouse SketchUp plugin. It is also missing the piece. The cut files on Wikihouse.cc are also missing the piece.

After combing through the Wikihouse newsgroups, we finally found the issue. The Wikihouse plugin has some protections to skip exporting small objects or those that don’t have faces that match and are aligned. Unfortunately, it does not warn you that it is omitting objects.

We ended up going into the plugin wikihouse.rb and changed:

1412: if area1 < 0

Re-running the Wikihouse plugin, the part is correctly exported in the SVG.

[caption id=”attachment_679” align=”alignnone” width=”300”][Missing piece is highlighted in green]1 Missing piece is highlighted in green[/caption]

We then convert the SVG to DXF in Adobe Illustrator. VCarve Pro is used to import the DXF and create all the part toolpaths.

[caption id=”attachment_677” align=”alignnone” width=”300”][Corrected toolpath file]2 Corrected toolpath file from VCarve Pro[/caption]

Wikihouse Build - Cutting & Assembling Calibration Test

What We Use

  1. Araucoply AC Exterior Plywood 4’x8’x23/32” S252. ShopBot PRS Standard 96x48 w/ Porter Cable Router3. SuperZero Fixture4. Raptor F/15-150 1.5” Polymer Finishing Nails5. Porter Cable #7310 Laminate Trimmer6. Onsrud Two Flute Straight Trim Bit


Since we’re starting a new project where accuracy is a factor, we start by re-surfacing our spoilboard. With a 1.125” diameter bit, this process takes about 20 minutes. Since our first layer is MDF, we do this more often than other shops and will never use MDF again. MDF expands and contracts a lot with humidity so our cutting surface is unstable for cutting very thin materials.

We simply place the plywood on the ShopBot table and make sure it is flush to the (0,0) so it is as square as possible.

Changing the bit

We start by setting up a 0.25” upcut end mill in the collet and doing our zeroing routine. We use a SuperZero so the process is mostly automated with all 3 axises being zeroed in about 30 seconds.

Using the SuperZero

Cutting the Parts

Out of software habit, we break up the part cutting into multiple files so there are a number of natural pauses in the machining. If something needs redone, a tool needs changed, or we need a snack, there are a number of stopping points. Probably unnecessary but a hard habit to break.

Our ShopBot doesn’t have a vacuum hold-down system so our cutting Step 0 is marking the material. Small, shallow pockets are cut around the material where it is safe to attach the material to the spoilboard. Marking should be heavy enough to see, but light enough to not shift the unsecured material when being marked. For attaching to the spoilboard some people use drywall screws. We use Raptor polymer nails that have hold down power but are easily sliced through by the router if we put one in the wrong place.

For Step 1, we cut the main parts. This process takes about 15 minutes.

In Step 2, we cut labels on the parts. We just use a series of circles to show part numbers instead of taking the time to carve actual fonts.

Finally, we cut some extra parts to use up the left over material. We added some more lock pieces since they are small and probably wear more.

Manually, we had the ShopBot cut our full sheet of plywood in half. We will save the extra half sheet to recut the Calibration Test if we don’t pass. This also makes it easier to move the half around with our parts since we have to flip it over to remove the tabs, freeing the parts.

Parts Cut

Remove Parts from Material

To remove the parts we machined in the material held in place by the tabs, we use a Porter Cable Laminate Trimmer. We flip the machined material over so the tabs are now face up. The bit is setup so it cuts deep enough to remove the tab but shallow enough to not go through the material. The trim bit does not have a live cutting edge on the tip so when you place the router into the groove, it won’t grab the material if you touch any. This is an important fact for safety. If there is a live edge and it grabs the material when you try to enter the groove, the torque of the router will easily rip it out of your hands and likely hurt you.

Determining where to place tabs and how many per side is a matter of practice with different bits and materials. On large parts, we try to place at least one tab per side placed away from corners. Sometimes we do more tabs on sides of the part that won’t be exposed in the final assembly.

20131101-153559_BE7f_FinePix X100

Assembling the Parts

We end up with seven main parts and a few small locking pieces. Since we couldn’t find any assembly instructions, we pulled the model of the Calibration Test up in SketchUp. After rotating the model around and removing parts, we figured out how everything goes together. The first problem is that we are missing a part. A locking component that holds the vertical spine together wasn’t exported from the Wikihouse Plugin. We think it may have been a grouped object so the plugin didn’t know how to render it to the SVG.

The next problem is that the parts are machined very accurately so they are a little too tight of a fit. We used a small orbital sander on many of the part edges. After about 30 minutes our build is complete.

20131101-163117_BE7f_FinePix X100

Wikihouse Build - Preparing Calibration Test Part Files

We’re going to to cut a wikihouse.cc to see what options we have for interior structures in a new workspace plan. We’ve been looking into shipping containers but they’re not turning out to be as cheap since shipping is on the rise or as easily modified as we’d like. Welding and plasma cutters are not on our list right now.

Wikihouses are constructed from plywood cut on a CNC router. Browsing their library of designs, we decided to build a Gwangju Prototype which is a Korean wikihouse design.

Getting Started

To get going, we first need to pass the Wikihouse Calibration Test. This is a small collection of parts to test the accuracy of your machine and a simple build of the common locking joint.

What We Used

  1. SketchUp Pro 2013 (SU2013)
  2. Wikihouse Plugin from the SketchUp Extension Warehouse
  3. Adobe Illustrator CS6 (AI)
  4. VCarve Pro 7.5 - ShopBot Edition (VCP)
  5. ShopBot PRS96 / Porter Cable Router

What We Did

File Conversion

  1. Opened Calibration Test in SU20132. Used Wikihouse Plugin to Export parts as SVG3. Opened SVG in Adobe Illustrator and converted to EPS.

Creating Shopbot File

  1. Opened Wikihouse Calibration EPS we converted in VCarve Pro
  2. Locked objects together when parts had internal pockets.

This keeps the alignment of pockets when we move a part around.

  1. Nested parts using:

a. 0.5” for Tool Dia, Clearance and Border Gap

b. 90deg Rotational step angle

c. nest from bottom left

d. Nest Along X

This resulted in parts fitting in a 48”x48” piece of plywood so we can get two attempts per full sheet.

  1. Unlocked all groups so we can edit the objects again.

  2. Added 0.125” Dog-Bone fillets for toolpaths.

The Wikihouse designs from Sketchup are laid out as ideal. Since we are cutting on a router, we can’t cut perfect right angles on internal pockets as drawn. The solution is to cut Dog Bones/T-Bones where extra material is removed on the interior corners. The parts will then fit together correctly.

  1. Since we have excess material, more locking parts were added to the sheet reducing waste.

  2. “0 Mark Hold-down” toolpath created to mark material where drywall screws can safely attach material to ShopBot spoilboard. 0.3” dia circles (slightly larger than our 0.25” bit) are cut 0.2” deep around the material. Screws prevent material from moving and reduce any warp in the plywood.

  3. “1 Cut Out Parts” toolpath is created for the main parts. All parts are cut using a Profile path with tabs added.

  4. “2 Label Parts” toolpath is created so each main part has a unique id. Now if a part has a problem, we can fix it in the part file easily. This project only uses two identical parts but labeling is still a good idea.

  5. “3 Cut Out Locks” toolpath is created to machine the extra lock parts we added to use up the material.

  6. Save ShopBot files.

Puppet Class Scope Gotcha

I’m in the process on refactoring our puppet mainfests based on the Node/Role/Profile/Module model from Craig Dunn’s article. I’m working with puppet 3.2 - so I don’t know if this applies to older versions.

I hit a terrible gotcha today. Basically you have to be very explicit in the way you setup the includes or puppet gets very confused about which module you mean to include.

I’m going to use Zamboni as the name for my module I want to wrap (can you tell I just got back from Canada?).

class zamboni {
  notice("Class zamboni included")

class role::zamboni {
  notice("Class role::zamboni included")
  include zamboni

class role::server { 
 notice("Class role::server included") 
 include role::zamboni

If you run this you will see (Your ip will depend on the box you are working with):

<pre>`* [] Notice: Scope(Class[Role::Server]): Class role::server included
* [] Notice: Scope(Class[Role::Zamboni]): Class role::zamboni included

You can see that the role::server is included. So is role::zamboni.  What is missing is the final include of the zamboni class itself.  This was really confusing.  I spent a while trying to get the dependencies to sort out before stumbling on the source of the problem.

I opened a [bug](http://projects.puppetlabs.com/issues/22219)  with Puppet to see if they will add a warning for this case (since it doesn't make sense to include a class in itself - or at least I don't think that makes sense).

In the mean time I can fall back on explicit scoping to get things to work -</pre>

<pre>`class zamboni {
  notice("Class zamboni included")

class role::zamboni {
  notice("Class role::zamboni included")
  include ::zamboni

class role::server {
  notice("Class role::server included")
  include role::zamboni

By referring to it with the explicit scope (:: is the base scope), the class will get included correctly.

.bashrc playing nice with rvm

In recent versions of Ubuntu (I’m looking at you Quantal) gnome terminal does not load the .bashrc properly when you create a new tab or spawn a new window.


I modified the profile on gnome terminal Edit > Profiles > Edit> Title and Command to set it “Run command as a login shell”


Then you just have to append sourcing this (which loads a local bashrc if you have on)

sudo sh -c ‘echo “[[ -s \”\$HOME/.bashrc\” ]] && . ~/.bashrc” >> /etc/bash.bashrc ‘


Then you can add your own customizations in ~/.bashrc and have them loaded everytime you spawn a new terminal.

I added the following to my own .bashrc

[[ -s “$HOME/.rvm/scripts/rvm” ]] && . “$HOME/.rvm/scripts/rvm”
RVM_DEFAULT=”ruby-1.9.3@home –create”
[[ -s “$HOME/.rvm/scripts/rvm” ]] && rvm use $RVM_DEFAULT

This makes sure that rvm is loaded and sets a default ruby with a gem set for global use.

The Write Tool for the Job

Lately, I’ve been working on a lot of documentation projects. That includes building up a manual for TruckingOffice ,and documenting the development process we use at nMany.

I’ve worked on large documents in the past in both Word and OpenOffice. You could write them, but they quickly became unwieldy. I switched over to LyX because it made it so much easier to build large structured documents.

Since it had been a while, I thought I would look around at the tools available. I’ve read a lot about self publishing. I downloaded a bunch of kindle samples on the subject (including APE which I recommend).

I tend to look for technologies that work well across platforms, since although I’m on Linux most of my co-workers run Macs. I’m generally obsessed with the safety provided by source code control in general (and git in specific) so I wanted something that would work with that as well. Being able to diff things and merge conflicts between writers would be a nice bonus (but that eliminates most binary formats).

A lot of the things I wanted where shaped by meeting the Pragmatic Programmers team a while ago. At the time they were working on a proprietary system to make it easy to auto generate books from xml/text so that they could source code control it and quickly generate new versions as bugs where found.

As I looked around, I went back to ebooks I’ve read lately. Several months ago I bought a book on Sublime Text because I wanted to evaluate it to see if I should give up RubyMine. In the process of researching more self publishing (since a lot of tools are being built for that market), I ran into an article by the guy who wrote the Sublime Text book. His article How I made $2,000 in 7 days launching my ebook pointed me at LeanPub as a cool platform.

Looking into it, I quickly fell in love. They handle writing documents in plain text with markdown. Their markdown has some improvements to give you features you need for a book (like call outs and sections). Since I can write chapters as seperate text files it is super easy to manage in git. They share a DropBox folder which is where you put content you want to publish.

The other thing that is great is the way you include code and images. You get to make references to external files for both of them. That means that I can leave code in a directory where I can run and test it, and whenever the book is generated I know that it will grab the latest version. The same thing for images. That means when I make a change I don’t have to fix, find, copy, and paste. I just edit the file in place and everything will just update.

They also handle generating the book in pdf, kindle, and mobile versions which is one less thing to think about.

I had a problem where the text file I generated had some kind of strange UTF-8 character at the beginning of each file. This cause the rendering of my book to go crazy. I sent them an email, and the next day they rolled out code that handled the problem.

When you combine the LeanPub platform with FocusWriter, it is amazing how much I get to focus on the writing part of the show. This is becoming my default stack for writing large documents.


p.s. I have one other writing project I’m hoping to announce shortly so stay tuned!