Archive for the 'Technology' Category

Out of the box, the Ultimaker shipped with a stable, but relatively ancient, version of the firmware. This, combined with the stable, but relatively ancient, version of ReplicatorG available from the Ultimaker site was sure to produce useful prints with a relatively minimal of fuss, but nothing that remotely approaches either the blazing speed or amazing quality possible from this printer.

To achieve that requires some significant upgrades to the software stack. And, in some cases, it requires outright replacing some of the pieces entirely.

While this writeup is specific to the Ultimaker, there is a lot of general knowledge in here, and the various bits of software are largely universal to a number of printers. When my Printrbot shows up, I’ll write a revised version specific to that printer while generalizing this a bit.

Note that this is all moving very quickly. When I first wrote this, it required about 3x more steps and was considerably more fragile. It is improving rapidly! However, there is still a long way to go before any of this is easy.

Note: At the time of writing, you need to perform both of these upgrades simultaneously. ReplicatorG really does’ want to talk to the new firmware (of course, by the time I write this, it’ll likely be fixed). Read the rest of this entry »

This is a short video of the printing of an Octopus I’ve been using as a test model. The Ultimaker is printing at 250% of normal speed. I started at 100% for the first layers until a solid base was created and then cranked the speed to 250%. It could go faster, I think.

At that speed, the quality of the print suffers a bit. I believe, is mostly due to slop in my belts. I need to print some belt tensioners which will take up the slack nicely.

The print quality is both better than the out of the box experience and tons faster.

This is the result of a combination of upgrades:

• Upgraded the Ultimaker’s firmware to the latest beta version. It has all kinds of features that enable both higher quality and higher speed prints.
• Upgraded to using Pronterface to send the G-Code to the printer. It allows for communication at 250kbaud and doesn’t periodically pause like Replicator-G does if you forget and leave the temperature monitor panel open.
• Moved to using SkeinForge-48 as the slicer.

All three of these tasks were a downright pain to do. All three have been written up in another post.

For now, enjoy some 3D printer music….

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…

Read the rest of this entry »

Throughout the anticipation of the delivery of the Ultimaker (4 to 6 weeks — as are pretty much all 3D printers these days!) and the week of assembly (another post), I spent a bunch of time researching software and otherwise attempting to grok the toolchain without a tool to apply the chain to.

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. Read the rest of this entry »

While I’m looking to the Ultimaker (see my previous post for thoughts on the Ultimaker) (now received– time to start assembly!) as my primary go-to, general purpose, home manufacturing device, I was both interested in a second printer as a platform for experimentation and as a secondary printer for when I need to turn out a bunch of stuff.

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 retainCount method just isn’t very useful as has been indicated in the answers to about a zillion StackOverflow questions.

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. Read the rest of this entry »

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).

Read the rest of this entry »

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.

Update: This article will be updated occasionally with new information as I run across it….

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). Read the rest of this entry »

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.