Some build notes from my Ultimaker build experience…..

Overall, it took me roughly 4 days to build the Ultimaker. The first two days were a couple of long stretches and the last two were much shorter. Tuning the device to yield usable prints has taken a bit more time, too, and I still have a long ways to go.

At left is a print made using the default firmware with relatively default settings in ReplicatorG. Stringy as heck, but otherwise quite good! Software and hardware tuning are reserved for another article.

This is some random build notes from the build and roughly correspond in order to the assembly instructions themselves.

By and large, assembly was relatively straightforward. The only real disaster I had was with the cooling fan used on the extruder. When I tried to mount it, it shattered — literally disintegrated into dozens of pieces — in my hand.

The Ultimaker arrives in a surprisingly small, heavy, box. No surprise; wood is heavy and the Ultimaker is largely a wooden box with some very crafty electronics built into it. Frankly, the laser-cut wood based construction is, in and of itself, a bit of a hobbyist kit revolution. Wood is cheap and very strong, yielding kits that can be quite precise, extremely durable, and still remain accessibly affordable.

Random notes below the fold…

The Ultimaker assembly guide starts here. It is mostly excellent — really, really, well done, in fact — but there are a couple of rough spots. Having written such step by step guides myself (though about 2 orders of magnitude fewer steps!), I found it amusing — though very occasionally frustrating — that the details sorta become more and more vague as you move through a section. Overall, really, this is a very very well done kit!

Tools

The Ultimaker ships with just about all the tools you’ll need. However, the supplied 2mm hex driver was wimpy and I had stripped mine at about the 70% assembled point. It is possible to “repair” by carefully sawing off the tip to expose some un-worn tip. However, a far better solution is to go down to your local metric-carrying hardware store and purchase a handful of 2mm drivers/tips.

You’ll definitely want a pair of thin needle nose pliers on hand. There are a couple of steps that require sticking a nut on a bolt in very out-of-the-way places, sometimes behind other stuff.

Included with the kit is some ~3/4″ wide blue Scotch 2090 tape that is used both during assembly and to cover the bed for purposes of printing. For the bed, grab some 3″ ScotchBlue 2090 Tape as it only takes 3 strips to cover the print bed, leaving two seams in the printing area of the bed (the seams cause noticeable lines in the bottom of your prints).

Make sure you have a fine flat file or fine grained sandpaper on hand. There are a number of steps that involve inserting wood tab A in wood slot B. If it is at all tight, sand down the tab a little bit to make it slide in easily. You don’t want it to be loose, but you really need to make sure the various wood parts fit together completely!

Assembly Notes: Frame

I assembled a Revision 3 Ultimaker. Notes will go stale with future revisions.

As noted in the instructions, you’ll really want to sand the burn marks off the one side of all the cut wood bits.

- When installing the limit switches, there is no need to tighten them. They all have to be calibrate at the end. The very end after you’ve aligned the extruder.

- When tightening the switches, there are no nuts. It is a metal on plastic threads affair and it is easy to strip the threads in the switch. Do not over tighten!

- When putting the frame together, make sure all pieces fit together snugly and uniformly tight. Don’t use the screws to pull things together. This is where you’ll likely need a bit of sanding/filing to ensure that everything fits without forcing. This is to ensure that the frame is square. If it isn’t, you are in for a world of hurt calibrating the printer later!

Assembly Notes: X-Y Motors

This was pretty straightforward, if a bit persnickety. In particular, keeping the three layers of wood, the motor, and the belt all aligned properly when attaching to the frame was quite the challenge.

- For the Y motor, make sure you get the wires behind the motor when you are mounting it! It is a pain to do so after the fact. There is slightly more of a gap between the wood bits and the rear wooden wall than the motor and the wall.

- It is easier to tackle one screw first than to try and deal with all four screws at once. Once you have one screw a turn or so into the motor, it’ll hang while you move wires about, re-align things, and verify the belts are still in the right spot.

- Don’t bother tightening down the X or Y motors. Both will need to be loose when you are assembling the axis and tightened afterwords.

X-Y axes

This was the step that both had me occasionally questioning my sanity and the first step where the assembly guide was slightly lacking. The warning at the top indicating that it is a tricky step is no joke.

- Stack up all the parts in assembly order. No, really, do this now. The belt claws are each composed of 5 stacked bits of wood that fit tightly around a bit of pipe. Keeping it all straight is critical.

- Make very sure you understand the orientation of the claws on the rods before sliding anything into place. It is very easy to get wrong (I did so 3 times on 2 of the 4 axis; derp). They aren’t kidding when they say to go ahead an align the belt in the clamp during assembly instead of doing it later! It is much much easier during assembly than after the fact.

- Don’t even think about tightening down any of the various pulleys at this time. Alignment is a whole different adventure awaiting in the next step and any tightening now will be a waste of time. You can tighten down the X-Y motors and their corresponding pulleys at this time as the only alignment is to ensure that the belts are nice and tight.

Assembly Notes: Extrusion Head

This was the step where I met with the Fan Disaster. It was also the step where the contents of my kit most differed from the instructions. In particular, I ended up with two bottom plates (8B); one without any bits attached to it and one wit the push-in fitting already in place.

Overall, the head is really quite an interesting and — frankly — awesome bit of design. With some tricky bits.

- When pushing the tube into the push-in fitting, it won’t back out. If you push it in too far, keep going and try again. You really do need the tube to stick out as much as documented and no more! Keep in mind that when you add the “horseshoe”, you’ll actually be backing out the tube by a little bit! Yes, this step is tricky.

- When choosing which hole to shove the wires and extruder into in the aluminum block, pay careful attention to both the photos and also have a look at various Ultimaker specific fan shroud designs on Thingiverse. You will want to replace the fan shroud that came with your Ultimaker as one of your first print jobs. Or, in my are….

- The head cooler fan that came with my kit was defective. Or, more specifically, it was made from a bad batch of plastic (irony) that left it incredibly brittle. When I tried to attach it to the head, it ended up shattering in my hands. Thus, I ended up with no extruder cooler and turned to Thingiverse to find a 40mm compatible fan shroud that I could use. I ended up designing a custom one derived from an existing design with a focus on printability even with the lack of a fan. Full story for another day.

- Sticking the X-Y head slide rods into the machine is really tricky. Be patient and take it slow. And, again, don’t bother tightening anything down too much. However, you can tighten down the belt clamps and I’ve found that on my Ultimaker, it really doesn’t matter how tight they are as they don’t overly tighten the long axis belts. In fact, I’m going to print some belt tensioners as I’m getting a bit of slop in the x-y axis.

- Aligning the extrusion head is very tedious, but take the time to do it right. I found that tightening down the pulleys at one end of the long axis belts first, then aligning everything and tightening down the other end was easier. It is made more tedious in that sometimes you can get everything aligned only to find that the pulley set screws are in an inaccessible position! Often, this can be remedied by either changing the length of the spacer object used for alignment or by aligning on the other end of the axis.

Assembly Notes: The Z Stage

This is definitely the stage that will call for a bit of sandpaper. There is nothing in these steps that is particularly tricky, but there are several steps within where the result can be a bit awry. For example, the right Z-stage arm on my ultimaker is slightly out of alignment, leading to the front right corner of my build stage being too low.

There are also a couple of bits in this step where I couldn’t help but think some design revisions were definitely in order. Noted inline.

- When putting the arms around the two slide bearings, make sure that the arms are fitting around the bearings tightly. You’ll probably want to use a bit of the sand paper to round off the corners in the slots that the bearings fit into. Just a bit.

- The “Drive Nut Assembly” is the one piece that seems almost shoddy on the entire assembly. The metal ovoid nut just doesn’t fit in the wood in a way that seems to stay stable. It likes to move around bit. In use, it doesn’t seem to matter, but it was certainly quite concerning during construction! Later, it becomes apparent why there is play in this part, but I still don’t think there needs to be this much play!

- When putting it all together, you’ll notice that the left side doesn’t screw into the back like the right side does. This is actually a critical part of making everything fit onto the 3 vertical bars without having to have everything perfectly and exactly aligned (which wooden based assembly makes impossible). This will be important in a later step.

- When mounting the bed on the wooden frame, go ahead and screw down the spring loaded spacer screws pretty far. Not so far that the spring is destroyed. When leveling the bed, it is much easier to raise the bed than adjust the Z axis top stop switch.

- When mounting the Z axis in the machine, it is pretty easy to pull the left side of the bed apart (see the step before last). Be careful. The left side won’t necessarily be totally tight and the play on the nut assembly in the middle means that the 3 vertical axis of motion do not have to be perfectly aligned and everything still works.

- When applying the blue tape, completely ignore the directions that say you should use a razor to make it all nice and neat within the laser cut perimeter. Hogwash. You want the tape to cover the entire bed except, maybe, the last 1/2″ or so of the back. In particular, some of the slicers end up letting the head heat up in the front left or rear left corner. If not covered in tape, it makes a hard to clean up mess. Also, you’ll be replacing the tape every dozen+ prints (or more) and, thus, it is easier to lift off if the tape is overlapping the sides and folded under.

- To clean the blue tape, use a bit of rubbing alcohol. This nicely removes any finger grease and dust that prevents adhesion of the first layer.

Assembly Notes: Material Feed Mechanism

There was nothing particularly tricky about this step. However, make very sure that you have the parts aligned as pictured. It is easy to turn one of the plastic parts around such that it seems like the screws are just out of alignment. If you force it, it will likely break (no, I didn’t force it).

The feed mechanism is interesting and elegant in many respects, but I also suspect it will be the first really major upgrade that I make to my Ultimaker. I would really like a feed mechanism that both combines more consistent push through with something that detects when a jam has occurred.

One tip; if you aren’t sure the filament is feeding, use a sharper and place a small dot on the filament before the feed mechanism. That makes it easy to see if it is moving along (though you might end up with a couple of very small discolored spots in the final print). Alternatively, look in the feeder tube as the feeder mechanism cuts texture into one side of the filament and you can see that moving along, if the feed is working.

Assembly Notes: Mounting the Electronics and Initial Tests

Again, nothing particular tricky in this step. However, only the Z-axis limit switch connections are actually labeled as to which connector on the board is top and which one is bottom. I managed to get both the X-Y backwards. Whoops.

- The Z axis limit switches are easy to configure without power to the unit since the Z axis motor is easy to spin manually. XY switches are also easier to adjust manually, but they also need to be tested while powered. When sliding the extrusion head in XY, it is easier to do so by grabbing and sliding the two claws instead of the head itself. This also puts less torsional stress on the rods and frame.

Once everything is wired up and powered on, with ReplicatorG installed correctly (start with ReplicatorG), then there are some final tests that you will want to run.

After you have configured the limit switches to stop the head/bed appropriately:

- Before powering up the Ultimaker, slide the extrusion head to the middle of the print surface and lower the print bed to about half way.

- In the ReplicatorG control panel, set the XY Feedrate slider to really slow. Hit the X+ button and then manually actuate the limit switch at the front right of the machine. The head should immediately stop moving. If it doesn’t, try hitting the front left switch. If that stops the motion, then you have the X axis stop switches mis-wired to the board. Power everything down and swap the two X limit switch connections on the board.

- Repeat for Y. Y- is to the front of the machine.

- Fire up the extruder to a temperature of ~220ºC and, once warm, manually shove filament through until it starts squirting out the head (don’t push too hard and make sure you unlatch the feeder mechanism’s pressure bolt first). Also try toggling the cooling fan to make sure it works.

At this point, you are ready for your first print. Calibration and tuning can come later.

In short, 3D printing requires a slew of tools and the tools are… ugh… unrefined, if not downright user abusive. Not that this comes as a surprise. Affordable 3D printing is a very new market and it’ll take a few years for the science to be nailed down enough that an easy UI can be wrapped around it.

And it is moving rapidly. Thus, if you are reading this anywhere after about 3 to 6 months from now, it is likely that the landscape has changed.

As well, this is a decidedly Mac OS X centric / Ultimaker centric view of the world. I’ll likely update again in a month or so after I’ve set up the Printrbot.

To drive a 3D printer, there are quite a few stages of software that are employed. In the maker world, there are generally multiple answers to any given stage in the overall chain. If you are working with a commercial printer, it is likely that the stages closest to the printer — the driver, assuredly, maybe more — are fixed.The stages generally are (each of which will be covered in more detail in subsequent posts):

1. Design & Modeling

Before you can print something, you have to have something to print!

Just like 2D images, there are quite a few ways you can use to create or obtain a 3D model for the purposes of printing. Regardless of which method or software you use, the end result pretty much must be an STL file which describes the geometry of the object to be printed. More precisely, an STL file is a fairly standard interchange data format that provides a minimal description of a 3D shape (without color, texture, lighting, or other decorations).

As for sources, a great starting point is Thingiverse which offers a huge library of digital designs aimed at created real, physical, objects. While there are non-3D-printing oriented designs, the majority of the things on the site are targeted to 3D printing and, thus, offer STL that is generally ready for the next step of processing. Most of the designs also offer the original editable models that can be modified at will.

If you want to design your own parts, there are a couple of different primary means of doing so. You can go with a CAD package of some kind which can range in price from free to about a bazillion dollars. On the free front, Google’s SketchUp is very popular but I find it to be maddeningly frustrating to use. Personally, I’ve settled on Punch! Software’s ViaCAD (Mac App Store) for $99. ViaCAD provides much better control and feedback over the modeling process and the 2D->3D integration makes modeling of many simple things quite trivially easy! While I also find ViaCAD frustrating, it at least feels like the frustration is my own doing and, thus far, the primary author of the package has been incredibly supportive in the user forums.

I’m really hoping Autodesk’s 123d is released for the Mac. Autodesk has also announced Inventor Fusion for the Mac; it looks to have considerable promise, too!

An alternative to CAD is to go with a parametric modeler like OpenSCAD. In OpenSCAD, you basically describe systems of equations to render your 3D objects. It solves a completely different problem than a draw-in-3D CAD solution. For example, this “thing” is a parametric box where you can easily determine the height, width, number of compartments, and wall thickness just by changing a couple of variables. Even cooler, this thing provides everything you need to generate and print Lego blocks, including the never-before-seen “trilego” (an example I printed is pictured to the left).

In any case, whatever means you choose of generating a model, the end result of this step is generally going to be an STL file; a minimalistic, unadorned, inventory of triangles that roughly (or accurately, depending on export settings) describe the shape.

2. Pre-press Preparation & Repair

If the output of step (1) is particular good, then this step is pretty much a non-step.

Namely, an STL file might have any number of errors within that are invisible when rendered to the screen, but may cause all kinds of problems in the next few steps.

As well, the object(s) described in the STL file may not be rotated correctly or might not be “on the bed”. That is, the object(s) need to be aligned such that “up” is in the direction of printing and the “bottom” is on the surface that represents the printer’s printing surface.

Thus, in this step, you should rotate the object into “printing orientation”. Most software offers some kind of representation of “printer plane” and, in the case of ReplicatorG, it provides a one step means of centering an object on the print bed and making sure it is actually on the bed. An example of ReplicatorG manipulating an Octopus STL can be seen at the right.

Netfabb Engines — another tool that I’ve used, but whose bugs are bad enough that I wouldn’t recommend — can detect and [maddeningly not due to bugs] repair errors in the geometry of the triangle mesh. Errors like triangles that are facing the wrong direction. Holes in the mesh that violate mesh consistency.

There are a number of other solutions out there; many many solutions, ranging from free to very very expensive.

3. Slicing & GCode generation

Once the STL has been cleaned up, the next step is to turn the objects into a stream of commands that can be sent to the 3D printer for the purposes of printing the object. While this is called slicing, that name is a woeful understatement as to exactly how complex, critical, and potentially time consuming this step can be.

A naive slicer might simply slice the model into a series of planar cross sections and then send the print head on a path of simply filling in each planar slice. Not only would this yield horrible print quality, but it would waste a ton of material. For example, given that octopus seen above, there is no reason why the entire head need be composed of solid plastic! Of course, nor can it be entirely empty as that would make it impossible to close over the top of the head because all that overhang over empty space would simply sag as it is printed!

So, typically, the slicer generates commands to move the print head along the outlines of the piece while also creating minimal fill to save material. But it can be even more complex than that! The slicing software may have the notion of head momentum, might have knowledge of the “stringiness” of material (the tendency for the material to draw out tiny threads when extrusion stops), and/or might model what happens as the head turns corners (extruded material behaves differently in a straight line vs. turning corners).

Or the slicing software might model many, many, other potential details. This is one step in the process where, truly, there are entire companies dedicated but doing nothing but generating the most efficient possible tool paths that produce the highest quality output.

And that output is gcode, a very widely used — standard, even — programming language for computer numerical control [CNC]. It is far from limited to 3D printers, controlling just about any CAM/CNC machines these days and having a history that spans back to the 1950s!

For 3D printing, the most popular gcode generator is SkeinForge. It works well and ReplicatorG typically comes with several versions built in. SkeinForge, however, is not fast.

Netfabb can also generate gcode. I haven’t tested the output yet (and intend to do so).

New to the maker/hobbyist market is Slic3r. It is reasonably fast and has a pretty straightforward UI. As it is pretty new, there aren’t much in the way of Ultimaker specific profiles available yet, but that is likely to change rapidly.

At the time of this writing, this is an area I’m actively investigating. SF+Replicator is woefully out of date, thus it is a matter of installing SF and using it from the command line. Slic3r looks very promising. Netfabb needs to be tested further as it has promising gcode generation capabilities, but can’t talk directly to any printer due to bugs [on the Mac version anyway].

4. Host Side Printer Driver

The host side printer driver deserves a mention. It is really simple in role, but very important. The job of the printer driver is simple; spew the gcode at the printer as fast as it can take it, but not faster. Ideally, the printer driver software should also be able to monitor things like the extruder temperature without screwing up the print, allow the user to interrupt the print, and provide a manual control mode for controlling the printer.

ReplicatorG mostly does this, but if you leave the control panel open during the print, it tends to make the print head pause periodically which causes blobbing.

Netfabb is supposed to be able to control the printer, but it doesn’t even detect the printer due to bugs in the current Mac OS X version.

Beyond that, there is Printrun, but it looks pretty tedious to install.

Of all the pieces in the puzzle that is 3D printing, this is the one that I’m likely the most tempted to roll my own Mac OS X specific solution. What is available is just really primitive and user abusive.

5. Printer Firmware

Of all the pieces, this is the one that I fully admit to understanding the least. Yet, it is critically important (i.e. I need to address my ignorance shortly).

Out of the box, the Ultimaker ships with relatively conservative printing firmware that isn’t particular fancy or fast, but produces relatively forgivable prints at a reasonable speed.

With the Marlin firmware, potentially insane speeds are possible while achieveing an even greater degree of accuracy.

Whereas the gcode generated is more or less limited to “go to this point at this base speed”, the firmware apparently controls things like acceleration and deceleration to make it possible to go from A to B at a very high rate of speed while also stopping exactly where expected and changing directions in a predictable fashion.

All in all, much to learn. Next, I’ll write up the build notes for the Ultimaker, including errata, hints, and the adventure that ensued when my extruder fan shattered and I had to figure out how to attach a different sized fan (hint: it involves designing a cooling solution that could be printed without a cooling fan in place… then printing it again with the rough version to produce a much better version).

Because I wasn’t going to be afraid to modify it, I wanted something pretty cheap. The RepRap platform seems pretty interesting, but it also seems semi-fragile (and feedback on various sites indicates that it is harder to keep aligned than others, though I don’t know how true that really is).

Along came the Printrbot Kickstarter project. I ended up funding that at the $424 level. I’ll use the Ultimaker to print all the plastic parts. The Printrbot is really pretty extraordinary. It is an elegantly simple design, has decent precision and, through its simplicity, is extremely customizable.

Also, the Printrbot story and the whole Kickstarter concept is pretty cool and this seemed like a perfect opportunity to jump in and fund something.

The documentation has this to say:

Important: This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it, while at the same time autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from this method.

Makes it pretty clear that you shouldn’t be calling retainCount, but it really doesn’t illuminate exactly how useless the method is outside of a very narrow context.

So, let us count the ways:

1. The absolute retain count of an object may change at any time once an object has been passed through any system API.
2. Any subclass of any system provided class counts as “through system API”; the retain count may be impacted by implementation details.
3. The retain count never reflects whether an object is autoreleased.
4. Autorelease is a per-thread concept whereas retain counts are global; race condition derived hilarity can easily ensue.
5. The retainCount method can never return 0.
6. Some classes are implemented as singletons some of the time.
7. Some classes may internally manipulate their retain count directly (I.e. no swizzle for you!).
8. While retain/release are effectively thread safe, there is always a race between calling retainCount and having the actual retain count change in some other execution context.

Bottom line: the only time the absolute retainCount can be conclusively used for analytic purposes is if you have the backtrace of every retain and release that contributed to the current retain count’s value (there is another use case, documented at the end). If you have that, then you don’t need the retain count and, fortunately, Instruments is already generally quite adept at producing a per-object inventory of retains and releases for you (see Analyzing Data with the Allocations Instrument“.

In general, you should consider the retain count as a delta. Your code causes the retain count to increase and decrease. You don’t +alloc an object with a retain count of 1. Instead, you +alloc an object with a retain count of +1. If you want that object to go away, you need to do something — release, always and eventually — that causes the retain count to be decremented by 1.

It really is that simple.

Almost.

Concurrency — whether through threading or GCD — throws a bit of a wrench in the works (as it always does). Namely, the retain count should really be considered as a per concurrency context delta. If thread or queue A wants to do something with object X, it should hold a +1 retainCount on X for the duration of said operation. One subtle detail that will bear repeating later; an autorelease‘d object does not contribute to thread safety. That is, if thread or queue A wants to pass X to thread or queue B, there must be an explicit retain in A that is balanced by a release (or synchronization event back to A) in B.

Now, some of the enumerated claims may either seem specious at best or, certainly, not obvious as to exactly how it undermines the validity of the retain count.

1. The absolute retain count of an object may change at any time once an object has been passed through any system API.

The system is free to retain and release any object at whim and, in fact, it will often do so. An object may be shoved into a collection, it might be cached into a map somewhere by a computed key, or it might be retain‘d long enough to survive enqueueing for execution asynchronously.

As well, the object may be retain’d then autorelease’d such that the retainCount will look like it is N when it is really, effectively, N-1. If that retain/autorelease happened in a queue somewhere, the number returned may imply a greater # of strong references than truly exist.

2. Any subclass of any system provided class counts as “through system API”; the retain count may be impacted by implementation details.

This is really the same point as the first, but emphasizes that all bets truly are off once you subclass a system class. As the system’s use of concurrency during drawing grows over time, you can expect that any UI related subclassed classes will likely have their retain counts manipulated across concurrency boundaries potentially frequently.

3. The retain count never reflects whether an object is autoreleased.

When you call autorelease, not much really happens. The object is neither retain‘d nor release‘s. Instead, it is added to the current per-thread autorelease pool. The release is effectively delayed until the pool is drained or deferred to the next outermost pool if the pool is popped without draining (which can happen due to bugs or exceptions [exceptions are an indication of bugs in and of themselves in Cocoa]).

Once an object is added to an autorelease pool, there is no way to query whether or not it is in such a state. Thus, whatever retain count is currently returned may not actually reflect the effective retain found at all.

4. Autorelease is a per-thread concept whereas retain counts are global; race condition derived hilarity can easily ensue.

But it gets worse (at least, worse for the developer making the mistake of thinking retainCount is meaningful).

The retain count of an object is actually global to all contexts of concurrency. An object has one and only one retain count. While calling retain and release are concurrency safe, there is no way to express call retain and don’t let another execution context increment or decrement it until I’m done pondering the return value.

5. The retainCount method can never return 0.

When an object’s retain count transitions from 1 to 0, the object is deallocated (usually). As a result, if you retainCount on a non-nil reference, it can never return zero because doing so would require calling a method on a deallocated object which is undefined behavior.

Or, to put it more bluntly, this can never work (Yes, I had to go there):

while([bg retainCount]!=0)
{
  [bg release];
}

One might claim that if you message nil, you’ll get 0 in return. True; but no code outside of a short circuit in objc_msgSend() is executed. That is, the method isn’t returning zero, the messaging mechanism is short circuiting prior to calling the method.

6. Some classes are implemented as singletons some of the time.

Consider:

NSNumber *n = [NSNumber numberWithInt: 4];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 4];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 42];
printf("%p rc: %u\n", n, [n retainCount]);
n = [NSNumber numberWithInt: 42];
printf("%p rc: %u\n", n, [n retainCount]);

And the output on i386:

0x115410 rc: 2
0x115410 rc: 3
0x115950 rc: 1
0x115df0 rc: 1

Now consider x86_64:

0x483 rc: 9223372036854775807
0x483 rc: 9223372036854775807
0x2a83 rc: 9223372036854775807
0x2a83 rc: 9223372036854775807

For this particular class, the behavior is different depending on value and depending on architecture. You could expect potentially even different behavior on an iOS device. Likewise, if you were to run the 64 bit variant on Snow Leopard, it would be different yet again!

Internally, NSNumber uses singletons for a small subset of values on certain platforms. On x86_64, it uses tagged pointers (Bavarious explains tagged pointers quite well in this blog post. I should update the objc_msgSend() tour to reflect the new messenger in Lion, too) to avoid allocating anything for the object altogether.

In all cases, relying upon the retain count of an NSNumber will create a dependency on system behavior that will quite likely change in the future, breaking your program rather badly.

Many other classes within the frameworks have similar optimizations for the common cases. Likewise, because of polymorphism and/or duck typing, it is likely that a system API declared to return an instance of, say, NSString might return an instance of a seemingly unrelated class whose interface is string compatible.

7. Some classes may internally manipulate their retain count directly (I.e. no swizzle for you!).

It may be tempting to override retain, release and autorelease in existing classes using a swizzling mechanism or the like. Depending on the class, you might find that the retain count of an object is changing more than the # of calls to retain/release/autorelease might otherwise warrant!

This is because a class might choose to implement a retain count mechanism differently than the one provided by NSObject and, thus, might internally directly manipulate the retain count without going through the various methods.

Since the retainCount of an object is not an observable property (ewww… boy howdy that’d be ugly if it was), this direct manipulation is perfectly valid. However, it means that you cannot count on being able to externally modify an existing class to observe the retain count.

Nor should you need to. The system classes are designed such that they should be compatible with the Allocation Instrument’s ability to track reference count changing events, including grabbing a backtrace. If you find a class that isn’t, file a bug, please.

8. While retain/release are effectively thread safe, there is always a race between calling retainCount and having the actual retain count change in some other execution context.

Mmm… concurrency… where 1+1 can yield 3.

As was mentioned before, there is no operation via which you can query an object for its retainCount in a fashion that guarantees the retain count won’t change immediately after you retrieve the value, including potentially deallocating the object.

That is to say, there is no retain/release locking mechanism.

Thus, as soon as you retrieve the retainCount of an object, that value may be incorrect unless you can absolutely guarantee that the object is not being manipulated by any other execution context. And the only way to guarantee that is to pretty much stick to a direct subclass of NSObject (which, in and of itself, isn’t really technically correct either) and limiting manipulation of said object(s) only to threads/queues where you exactly control every aspect of interaction with said object; i.e. no system APIs for you!

The above doesn’t even consider the inherent design fragility in colluding the reference count of objects with other functionality. The classic “scarce resource recollection” problem of GC very much exists in a manual retain-release realm, for example.

So, when is retainCount useful?

I have encountered a handful of cases where the retain count of an object was used internally as a sort of “mode of use” indicator. That is, if an object’s retainCount is 2 when -release is invoked, the framework will assume, say, that the object is transitioning from “in use” to “available for quick reuse”. Typically, this is a sort of allocation cache or instance cache. Often, this is done because instantiation of the object is fairly expensive and, thus, the goal is to create a pool of available objects that can quickly be reused.

While a valid use, it tends to be fragile and tends to make crashes more difficult to analyze. Namely, one stray release or autorelease and you are likely to have a crash in the caching mechanism. At least with a crash in in NSAutoreleasePool, it is immediately obvious where things went off the rails.

A far less fragile solution is to encapsulate the expensive bits within a second container within the object. That container can be “checked in” and “checked out” by the object as a normal part of allocation/deallocation. This decouples cache magic from retain count.

The best possible solution to all of this is to move to ARC! Automatic Reference Counting, by and large, works incredibly well for a technology that is so new. The compiler and runtime teams have taken a very conservative approach that makes this so. Basically, if the compiler can’t reason through a piece of code to determine with total certainty exactly what the retain/release behavior should be, it generates an error instead.

It works quite well and many of Apple’s newer releases feature big chunks of code that are ARC’d.

If you can’t go ARC yet for whatever reasons, then dealing with manual retain-release is really quite simple and covered well in the documentation. The key is to ignore the retain count as a value and treat it purely as something you increase and decrease; you must balance every increase with a decrease if you want a particular object to be deallocated or over-released in the case of too many decrements.

This is our AeroGarden after a couple of months of growth. It is currently growing savory, mint, basil, thyme, parsley, amaranth, and oregano. The Aero works really really well. Within the water reservoir (the big black thing under the plants), it has a pump that pumps water with nutrients over the roots of the little growing pods that stick through the holes in the deck around the plants. Surprisingly, the thing makes virtually no noise.

Once every week to 14 days (not sure how often), it reminds you to add nutrients and it has a water-low indicator. While the seed kits from Aero include nutrients, I’ve been using the worm tea from my son’s worm farm.

Quite nice to have a nearly non-stop supply of fresh herbs next to the kitchen!

I would never have otherwise bought such a device, but we ran across one at a garage sale for $5. Quite a hefty discount off of the $150 new price. It did need some new lights.

I picked up one of the Aero branded seed packets so I could go through one grow cycle by the book, as it were.

$150 seems a bit steep and seed kits are another $20, typically. However, if you truly will use all the herbs, then I would think the thing would pay for itself long before it wears out. Annoyingly, the light sockets are of an esoteric standard and ordering new lamps from Aero is ridiculously pricy. Razor meet blades, assuredly. However, it isn’t hard to rewire it for standard CFL grow lamps (you want CFL to avoid burning the plants at such close proximity).

Once I have my 3D printer up and running, I plan on printing new grow pods customized to work a little better than the official, cheap, ones.

As well, I’ll likely replace the entire lamp unit with an all LED unit (custom printed, of course).

I’m also going to place a bit of either mylar or aluminum hanging down from the lamp shade. That will reflect the light back onto the plants and, from reading the forums, prevents the plants from being quite so lanky.

Mint Tea

With the mint from the unit, I’ve been enjoying mint tea. Simply toss a bunch of mint leaves into a pot on the stove and boil it for a few minutes. More mint, the stronger. Strain into a mug and squeeze in a bit of lemon and honey.

Yum.

Every year, our neighborhood has an annual ornament exchange.

This year, we hosted the party at our house.

For our ornament, I picked up a bunch of matte finished shatterproof (i.e. plastic) ornaments from Amazon.com and shoved ‘em in EMSL’s Egg-Bot.

For the artwork, I found an elevation illustration of the front of a typical Eichler and used Inkscape to trace a relatively minimal line drawing of the elevation (attached below).

Worked great! The person that received their ornament loved it and, of course, then everyone else wanted one, too. No problem! I printed ‘em up in whatever color combinations folks wanted.

When loaded in Inkscape, the lettering and wreath on the door are in a different layer than the house line art. The Egg-Bot Inkscape driver makes it easy to print a layer at a time and, because the stepper motors stay powered unless you explicitly turn them off, you can easily swap pens after a layer is printed without knocking things out of alignment.

If you have an Egg-Bot, those particular ornaments + Sharpie ultra-fine markers are pretty much an optimal combination. You don’t even need to take the little hanger top off when printing. As can be seen in the photo on the left, the ornament part fits well into the cup of the egg holder and the plastic eye is held quite firmly by the spring loaded part of the Egg-Bot’s egg holder.

Gonna be a long 4 to 6 weeks…

I just ordered an Ultimaker 3D printer after a few weeks of on and off research into the subject of 3D printing. It has a 4 to 6 week lead time.

I chose the Ultimaker over the RepRap Mendel/Prusa, MakerBot, and UP! Personal Portable 3D Printer for a few reasons:

- Larger build envelope than the Makerbot and faster, too.

- Extremely precise print capabilities.

- Less finicky than the Mendel, so it seems from the various forums, etc.

- The Netfabb software seems to be well regarded.

- Elegant print head design.

- Highly customizable, open source hardware / software / platform.

- PLA preferred (PLA is Polylactic Acid and is a biodegradable, non-toxic, material)

Any of the 3D printers would have been a good choice and each of the ones not chosen have advantages; the makerbot has an automatic object ejector for continuous duty printing, the UP! is a really nice design (easy to use), and the RepRap has an awesome community supporting it that has built a very versatile/customizable platform.

There are, of course, a large number of commercial printers. The UP! is about the cheapest of the lot and pricing ranges right on up to $unobtanium. Extrusion based printing is not the only solution, either, by any means, but it is currently the most accessible, as far as I can tell.

In the end, the elegant extruder design, overall machine design, speed and — most importantly — accuracy of the Ultimaker won out. I suspect I’ll eventually build a 3D printer of some sort, possibly a RepRap, or, at the least, print parts for someone else and help them put it together. Seems like a fun project and, overall, 3D printing is likely to be a huge industry in the coming years.

I have about a zillion little projects around the house that I can knock off with a 3D printer:

- new shower bar end cap so the shower door doesn’t bump into it

- proper clips to hold the art glass in the cabinet doors throughout the kitchen (the glass is a nonstandard thickness)

- seal for my bike light

- Lens hoods for my various lenses

- seed baskets for an AeroGarden (found a 7 hole one for $5 at a garage sale)

- seed/grow baskets for a homebrew aeroponics/aquaponics system I’m contemplating (I want fresh salad all winter long, thanks!)

- iPad stand

- various cable keepers

- deflector for the front of a meat grinder to keep it from squirting blood everywhere

- fully customized project boxes

- custom Legos

- custom LED/CFL lighting fixtures

- Fractals

- whatever the hell Roger wants to print

That last one is the most important. I can only imagine how awesome it would have been to have a 3D printer when I was 11 years old. Should be a great educational tool for him. It’ll also be fun to put it together with him. He is both a talented solderer and totally enjoyed putting together the Egg-Bot (speaking of — I wonder if I can print the mechanics for a new, larger, Egg-Bot).

There was a Kickstarter for Printrbot: Your First 3D Printer. I bought into that at the $424 level; I should receive everything to make one, save for the parts that I’ll need to print on the Ultimaker.

The goal isn’t to have 2 3D printers, but to use the Printrbot as a hacking target for some other ideas I have.

To answer some questions:

Are you taking third party orders? I have a homebrew mount for my mobile phone in my car made out of foamboard that I would love to have a less-ghetto version. Can you build up a 3-D model from basic geometrics shapes and print that without a physical model?

Sure and Yes, you can. There are all kinds of ways to build up printable models. You can start with just about any of the models on Thingiverse. Or you can use any of a number of third party tools, both in the drawing realm and in the algorithmic/parametric realm, to generate models. The trick will be to learn how to produce models that are both usable and print well; there are limits to how much overhang and the like you can have.

(Ooh! Cool! Custom Lego!)

Do you have an estimate of how much the PLA plastic costs for some of the items on your list?

It looks like PLA is pretty much a commodity item and the price is varying day by day. I picked up two 5 lbs reels (one black, one white) for ~$60/each. I don’t yet know how far that will go, but I do know that it is largely a function of the models being printed, how “solid” the interiors need to be (which is largely dictated by model) and, of course, how many times I screw up!

An unremarkable, though rather pleasant, picture of the creek near my parent’s house in Missouri.

What is remarkable or, at least, exceptional about this photo is that it was taken about 30 seconds after I fell in the creek (slick rock) and dunked both my iPhone and my Canon DSLR (t1i) underwater for a good 5 to 10 seconds. While bummed that it happened, I wasn’t really angry — it was inevitable and, given how much joy the various photos have brought the family and how much educational value they have had for Roger, the risk has been worth it.

This was the last photo the camera took for quite some time and, at the time, the last photo I expected it to ever take. My iPhone was in similar dire straits. Upon removal from my pocket, it had flipped out; cycling between screens, waking sleeping, etc.. Water drained out of the headphone port.

OOops.

Same with the camera; had to dump water out through the lens mount, through the battery compartment and out the SD card slot.

Leaving them in a sunny spot in an air conditioned, and thus relatively dry, house, the iPhone started working just fine, though the camera lens had a bunch of moisture on the inside. That dissipated within a few days and, save for the occasional mysterious “GPS on all the time” mode, the iPhone seems completely normal now.

The camera took longer to return to normalcy. For the first few days, it would power on to a “set the time” screen and I would then turn it off, remove the battery, open every door/compartment/etc, and let it dry some more. After the first week, it mostly just worked, but the flash stopped popping up for a while. Now even that seems to work.

It seems I got lucky. This time.

I’ve also been behind on cooking, making stuff, etc…

After letting my Sous Vide Supreme gather dust for a couple of months, I thought through why and what to do about fixing this.   The quality of food that is possible with SV cooking was clearly a motivator.  What I concluded was that the size and pain of storing the SVS was ultimately the reason why I didn’t use it;  finding a place to store was a pain and the SVS always takes the same rather large volume of water, even if you only want to cook a few eggs or a couple of steaks.

Thus, after some rather extensive research, I decided to go with a PolyScience Sous Vide Professional.   Effectively, it is a PolyScience lab circulator refactored into a form convenient for use in a kitchen.   It is easy to use, very accurate, and — most critically for me — can handle both a much much smaller and, on those occasions where I need it, a significantly larger (30L) volume of water vs. the SVS.

Once obtaining said device, a bit of a food adventure has been had over the past few weeks.

Ribs & Pork Shoulder (24 hours @ 56ºC)

Ribs were basted with an apricot / rice vinegar / EVOO / brown sugar / ginger sauce prior to bagging.   Pork shoulder was rubbed down with brown sugar, light salt, and scotch bonnet pepper flakes.

End result was quite good;  both the ribs and the shoulder had “chew” in that they didn’t entirely fall apart, but were still completely fork tender.   Flavor profile was excellent;  intensely pork flavored without being overbearing.   The belly was slightly salty and, in fact, salting in sous vide is very different than salting in regular bbq.

Lesson Learned: What is likely obvious to anyone who can actually cook;  any liquid in the sous vide bag should be drained into a pan and used to make a sauce, some sauce, any sauce.   Use it to deglaze a pan.  Add it to some sauce you are making, even if you have to cook it down a bit.   There is simply too much deliciousness in the liquid in the bag to let it go down the drain!

Fillet of Salmon (30 minutes @ 54ºC)

Just hot enough to pasteurize, no more.  Sadly, this sucked.  But it was an important lesson.  The Salmon fillet was absolutely perfect in texture and color, but the flavor was off.  Namely, it was fishy because I had abused the fillet between freezer and consumption.  Not “I’m going to die” fishy, but just unpleasant.   Frankly, if I had cooked it in a stew or grilled it, it would have been fine.

Lesson Learned: When cooking SV, there is nowhere that any off flavors can escape to, be burned off, or otherwise be covered.  While you don’t have to start with the most amazing quality ingredients, they must be absolutely fresh and/or have been stored properly every step of the way between harvest and table.

Brisket — French Laundry Style (48 hours @ 64ºC)

Picked up a big chunk of relatively cheap brisket and cut it into three pieces.  All three were oiled, salted and peppered prior to bagging.  One then had a hot indian curry added and one had a bunch of Worcestershire + Maple Syrup.

End result was very interesting.  It was a lot less tender than I expected, but was still fork tender after being sliced across the grain.

All of the juices were drained into a small cast iron pot and were cooked down with powdered mustard, ketchup, and siracha until it thickened into what turned into a delicious BBQ sauce.

Lesson Learned: Following Keller’s temperature and time recommendations seems to “just work”.  This comes as know surprise.  However, if you read many of Keller’s SV recipes, they generally require a proper vacuum sealer to be able to achieve the “under pressure” part of SV cooking.

Cheap Steaks (48 hours @ 56ºC)

Picked up some cheap sirloin steaks.  Not terribly tender, but not too tough.  Decided to do them 48 hours to see what would happen;  one plain, one curry, and one maple syrup + Worcestershire.

Browned meat over high flame on cast iron after.

Made sauce out of the juice, of course.

Was quite delicious, but the meat texture was too tender.  Beyond fork tender.

Lesson Learned: No, really, you can make a meat too tender.  At least, if you expect to serve it in a steak-like format.  However, I’m betting that taking the same cut of meat, dropping a bunch of stew like veggies and spices into the bag, and cooking that for 48 hours in a similar way would result in an amazing stew.

Peaches (3 hours @ 80ºC)

Peaches + brown sugar + bourbon, actually.   Just an experiment.

Delicious over ice cream, but the bourbon flavor was surprisingly strong.  In hindsight, this should have been obvious.   Did this a second time and used the result in a BBQ sauce described below.

Lesson learned: The Sous Vide pouches are a closed systems.  Any flavors that go in will stay there.  They may change from being exposed to said temperature, but they can’t escape!  Duh!  So, like salt, if you have something that is an intense flavor that would otherwise be somewhat lost during cooking, vastly reduce the amount you put in!

Brisket — Baldwin Style (24 hours @ 80ºC)

Didn’t have 48 hours and wanted to try something a little different.  Did the three flavors again as described above.

Browned the meat in skillet before, on grill after.

The end result was much much more tender than the French Laundry Style described above. But that may also have been because the meat, itself, was significantly fattier.

Served with a BBQ sauce made from the SV peaches described above + brisket SV juices + ketchup + maple syrup + mustard + hot peppers.

Lesson Learned: Beyond the exceptionally well understood pasteurization tables and exactly what temperature to cook a piece of meat to consider it “rare, medium-rare, etc..”, the relationship between time/temperature vs. resulting texture is not entirely understood by anyone. Certainly, a truly competent chef will find a particular time/temperature

Leg of Lamb (24 hours @ 54ºC)

Took a leg of lamb, shoved it in a bag without anything else, and SV’d it for 24 hours.

Once done, salted, peppered, EVOO, and then grilled for a minute per side on a very high heat gas grill.

Using the leftover BBQ sauce from the previous night as a base, I added the juice from the lamb SV bag and cooked it down a bit more.

The meat was perfectly tender and medium-rare from edge to edge.  Not a bit of it was left at the end of the meal.

Lesson Learned: 54ºC is a magic number.  At 54ºC, you can mostly cook something for up to 72 hours with no worries of poisoning anyone and still result in a piece of medium rare meat.  Mostly (as there is some subtlety to the whole pasteurization thing).  Just start with a fresh and competently handled piece of meat — it can be cheap, but it must be fresh.

Pork Ribs (24 hours @ 57ºC)

Dry rub with brown sugar, salt, hot pepper, ginger, and garlic.  Into the bag for 24 hours.  Cooked down a BBQ sauce (carry over from the one above), glazed and then seared over a high heat gas fired grill.

The texture of the meat was perfect.   The flavor was too damned salty.  Not inedibly so; just much more so than desired.

Lesson re-learned: No matter how little salt you use in a Sous Vide bag, it can easily be too much.  I didn’t even think I’d used that much salt, but the end result was still saltier than expected and saltier than desired.

More notes as I figure this out….

This year, we decorated our eggs using Evil Mad Scientist Laboratories’ Egg-Bot.

I picked up the kit from EMSL a few months ago. Roger and I put it together over a few evenings. Software installation is relatively easy (for an X11 app) and usage is quite easy.

The assembly, no surprise for an EMSL kit, was a breeze, with a extremely well written and illustrated assembly manual. Seriously — EMSL kits are the best kits I have ever assembled!

The Egg-Bot can draw on pretty much anything round that is smaller than a tennis ball; eggs of all types, light bulbs, golf balls, Christmas ornaments, and — even — fruit (I used a lemon for test purposes).

The trick is finding a marking instrument that is appropriate to the target surface. For eggs, Sharpies work quite well, but Bic Mark-It markers are too runny.

Precisely, the Sharpie Ultra Fine Point Permanent Markers, 5 Colored Markers(37675) works very well. Regular Sharpies do not; too fat. However, EMSL has various accessories available, including an “extra wide” pen holder (ordering that very soon!).

For test purposes, a pencil works well enough and can generally be erased.

When the Egg-Bot is drawing anything with curves or diagonal lines, it is almost musical in the way the various stepper motors play different tones.

Finding various bits of art proves quite easy. Basically, any random SVG based illustration will work with a bit of scaling and tweaking. Google’s Image Search can narrow the search by file type.

Alternatively, Inkscape uses Python as an extension language and I was able to whip up a programmatic image generator in just a few minutes.

As well, there are some hacks that involve replacing the pen with an engraving tool (a pecker type engraver). Might have to explore that!

Programming? Robots? Assemble something cool with my kid? Produce awesome designs that make the non-technical happy? Infinite repository of art easily searchable? Easy to use? Worth every penny!