Nanotechnology

I finally got the invitation to Google Communities and joined the first 3D Printing group I saw. It turns out it's pretty much like following the people in my 3D Printing circle of the same name, except the scope is a bit wider. There are some posts I either missed or wasn't seeing, and some I can do without. There are more people of course, some with good information or opinions and others that are on the periphery or complete novices. It's a bit of a wash that way; there is more data, but less information density.

I'm not convinced yet on whether communities will take off. I can't see how to filter out everything that hasn't been +1'd yet (there's an opportunity for a coined verb if I ever saw one - the act of clicking +1 on Google Plus: how about plussed or plownd or plumped), but that's a natural extension that would be easy to do. You can model it after the system on /.

So anyway, the reason I'm writing this is one comment from a guy, who was already in my circles, on a post by a novice who asked "How big is the gap between a 3D printing machine and a personal fabricator?" Here's the money quote:

Basically, no, you're never going to be able to say "tea, earl grey, hot" and have a machine fabricate whatever you want out of atomic structures.

To which I heartily disagree and call bullshit.

Now granted, it may not be realized in my lifetime, but the fact that plants and people have already created it, is an existence proof that it's possible to construct it - even more so when it's done purposefully either by an organism or a machine. But, it won't be done by the bulk processes we have now.

The dialog around the post did include the words nanotechnology, but not in the way I've always thought of it. To me nanotechnology has always meant the ideas championed by K.Eric Drexler, especially in the mind blowing tome:

K.Eric Drexler, Nanosystems: Molecular Machinery, Manufacturing, and Computation (New York: John Wiley &Sons, Inc, 1992).

This book, based on his PhD dissertation, and his other more accessible previous work Engines of Creation were based on the There's plenty of room at the bottom lecture by my personal hero Richard Feynman. If you haven't read any of the above, I would recommend doing so at the next opportunity.

So, yes, it will be possible to construct any physically possible arrangement of atoms. The original question about what's the gap between the current technology and the possibilities as envisioned is simple to answer: it's a very large one. But even now, the differences are more subtle and nuanced than they were, just as the question of machine intelligence can now be answered affirmatively albeit with many caveats and conditions.

GnuPG

If you want to use encryption on emails you send, you have to:

1. have a program to encrypt and decrypt text like GnuPG
2. have somebody's public key

Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.17 (MingW32)

mQENBE2z3s4BCADhbXqd+vRmuuzLWOZKyg1gJ1ds2ZQih0pAfm4SRU4q8sn+dcUP
D2jI9rsZkMrZ+mcSNyvPiENQjl8wYpjpt9POJLhDI3yqCUU759375vUYa96/TK5Q
kPFnO1Yt1QWZKc1UsgyqnjI4qLo6BhjXaLG3rZcY0koAMTlf/rHsQmFJewjAuy2l
KpC48ZYrh3AucdqV+on2g7auJ0zR9Jp1NDKJPCdoALQP6Q7CKRvlQe0gnIItkGch
6tjkMbr/hZh9JQ9IqTCkf41htDK4UZCj3U0uW77lkarTlYswViAtxob5pTf9j29S
XBm6Webt7hFf4Ohs9vUNO5Qf+9eODck/pvRdABEBAAG0WkRlcnJpY2sgT3N3YWxk
IChOb3JtYWwgc2lnbmluZyBrZXkgdXNpbmcgR251UEcga2V5IGdlbmVyYXRpb24u
KSA8ZGVycmljay5vc3dhbGRAZ21haWwuY29tPokBPgQTAQIAKAUCTbPezgIbAwUJ
A8JnAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcwh3aAFo4hvSKAf9GZuW
Q7ueYbaJSw5B3ttS815zBM9dvieSlMI3E2wb+3c/8Rty80jI21KFODbwOwn6Wxum
gaJfrTHGd+BHzoDuagmjqlp8SyVbo2OpbdOHjAXi3RJwdloo87sZCKBemWqZ+Fct
UeU3JzwuGjAPQ6Wx/cGlCKniXKVBsdltPfy3rIWwUzlUj2HNM4S21j+tLbHd/maM
scxw3ufxLk0gw5EiuQGCumR8nTLtvYECnjR3lNvmFOUE03pudLaKOkh1R0QOM57u
BJPnBhFjgTgUTtPOal6Y70SejICCIdd73m19MTIApoXjtLv1aeNQkQYZ+WGJjaDk
Fysev2+rw9SdWQf+srkBDQRNs97OAQgAry/44nBuEQb5oX6PSretaWfslRkqa154
sPwxmvQbmFBmOLJDfkv+2/m6gBA3OB1hA8NBYSwwAmXJMKQQlAm6zXGUe1MF/iby
rHxqTnGxLODeXYWo0ivLOcb8/sCgfwPYKCuI4zKIdC48kq1GvRFoJCx+pc8O4V9W
+L5YN9IH2S2R023qLZW21tDeUD3io+GC54YeR4BD4A761H+qARutkMSf7GHrKnSK
RpJi+6HJ2K9c+mVYJkSzJs+E47qMSKgyNNZ5Ru+KDyzB7+sCo0Y81WSVWDA28Aw7
TT92iz64cArhMhbdAzDozDy8fTHmfFD7TPFLvU2QBAMkNVtVEMQm0wARAQABiQEl
BBgBAgAPBQJNs97OAhsMBQkDwmcAAAoJEHMId2gBaOIbjW4H/R1upuX/nvp3JjjL
cuCw0qCsLVlXcmSq91P34gDsitC6LLw9oOqoRnBShiYkrDzBRdROV6o8A2DLBUOw
iYOWldLcXFUvfhskFWJB9LXcwSHcERSOoytyBT49BS1VZjYumrxA7tmhwPcZJQRK
8moZ4GGh+jlEYk07KfYrgKcWfTBr4y0mairRfShJ0bkn90S45+0KZ1+L6FvVMcz9
97wTuORbjkppSUgIzkoJNQvHx5KGEM8OEAxfpQNTjn+yygzy8hrY6+7pXA71gCwZ
Lbcf4VKdXitec/+W7xD9cnizIeP352S3rIl7qJCymzeS5nh9zesT9Sxo6OJbRz9M
/26RpiE=
=tTO0
-----END PGP PUBLIC KEY BLOCK-----

File name: 45595F7674B3E29228BBCEA1730877680168E21B.asc

Go on the Pi

If you have a Raspberry Pi and you want to program it, there are a lot of choices. Here's another: Go.

You're probably wondering why Go? Well, it's got some good libraries for networking and the binaries it makes are statically linked (albeit huge) so you don't need any supporting runtime when you ship a program. It's also cross platform enough so that the same program compiles on Windows and the Pi.

There are a few problems with it too. I would argue that Go is the ugliest looking language in the world because it forces K & R style braces - always. And the debugger is gdb, which I compare only slightly favourably with repeatedly poking a sharp stick in your eye. But hey, it's only a system the size of a credit card, what do you expect. I've worked on many embedded systems that have far more arcane (and expensive) tool chains.

Many others have got Go running on the Pi. ARM is one of the supported architectures. But since there are no binary packages available, this means installing from source. In case I have to do this a third time because I'm an idiot and baffed the SD Card image again (don't mess with the files in /etc/sudoers.d without enabling a root passwd), I'm recording the steps here:

Set the memory split for the pi, to the maximum for the CPU using:
sudo raspi-config
and the memory_split option.

Start by getting mercurial running:
sudo apt-get install mercurial

As suggested add these lines to /etc/mercurial/hgrc:
[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

Get the GO source code.
cd /usr/local
sudo hg clone -u release https://code.google.com/p/go
(note: this takes a while)

Then update to the tip so that the ARM 7 support is available:
cd go
sudo hg update -C tip

Build the go runtime and binaries:
cd go/src
export GOARM=7
sudo ./all.bash
(note: this takes a real long time)

Test it out:
export PATH=$PATH:/usr/local/go/bin
Create a file hello.go containing:
package main
import "fmt"
func main() {
    fmt.Printf("hello, world\n")
}

Then run it with the go tool:
go run hello.go
which produces:
hello, world

Oops

Here's a tip for you.

If you use Cura, don't put any valuable files in the Cura directory, because if you ever uninstall it, for example to upgrade the version, it erases everything in that directory tree.

Lesson learned. All the configuration files, scripts and command files that I had constructed to make that program work better are now history. Maybe I should file a bug, or submit a patch, but there are bigger issues with Cura than a flawed uninstall strategy.

Git on GDrive

I need to get stuff backed up. I've been programming too long without a net now. By that I mean I should be using Source Control Management (SCM) or at least some sort of Revision Control (RC) besides copying files to a thumb drive every so often.

I could push the projects to github or sourceforge, but then they would be public and I don't think I'm ready for that yet.

You can pay a monthly fee to github of course, and get private storage, but does it sound like I'm the kind of person who would pay a monthly fee?

So anyway, if you want to push stuff to the cloud, and you're using Git, you can use GDrive as the data storage site (or others like dropbox) by following the instructions (google search for "git" and "google drive"), but only if you're using Linux. Here's the instructions when using Windows.

Make a directory in your Google Drive local directory to hold all your projects:
cd C:\Data Files\Personal\Google Drive
mkdir git
cd git

Make a directory for a project and initialize git there:
"\Program Files\Git\bin\git.exe" init myproject.git -–bare

Each project should be given a new directory (myproject.git is the directory in the above command).

Now change to the project working directory - where you work on it. Initialize git there (if you're not already using it) and establish a remote (called gdrive below) to the created project directory in the Google Drive directory:
"\Program Files\Git\bin\git.exe" init
"\Program Files\Git\bin\git.exe" remote add gdrive "file:///C:/Data Files/Personal/Google Drive/git/myproject.git"

Note the syntax for the file URL is the keyword file, a colon and 3 slashes. This is important, otherwise you get an error like:
ssh: file: no address associated with name

This directory will have all the build artifacts, so you will probably want to clean it up first, but then add all the files in it, commit, and post to the remote (GDrive):
"\Program Files\Git\bin\git.exe" add .
"\Program Files\Git\bin\git.exe" commit --message "First commit to GDrive"
"\Program Files\Git\bin\git.exe" push gdrive master

When GDrive finishes syncing up the directory you're good to go.

Arcs

The toolchain for 3D printers is broken.
By that I mean there is a fundamental flaw in it; at least for regular geometrical objects. The process is good for Yoda heads and other objects extracted from 3D scans, but it fails for designed objects that have anything other than rectilinear forms.
The fundamental problem is using STL files as an intermediate format. The contents of this file type is a series of triangles that describe the exterior boundary of the solid. If the design that creates the STL files has a cylindrical, spherical or other curvilinear solid body, the program that generates the STL file has to approximate this with a tessellated surface. Even very simple solids can generate thousands of planar faces in trying to represent the design in the limited vocabulary of planar triangles.
As an example, consider the simple cylindrical object and its STL equivalent:

Obviously, storing the three coordinates of each of the three triangle vertices and three direction numbers for the normal, takes considerable storage. This STL file is 100KB for an exceedingly simple object. This is the result for a high resolution output, but reducing the resolution causes more deviation between the flat triangles and the original object - in other words the printed object is not what was designed; holes get smaller, you can see facets instead of smooth surfaces, etc. As the hole size gets smaller the facets need to get smaller to keep the surface deviation small, so the number of facets is mostly independent of the scale of the object.
The problem is, downstream programs like ReplicatorG, Cura and Slic3r need to process all this crap data. The generated G code file for this example is 750KB. This is why slicing takes so long and baud rates to the machine need to be as high as possible.
There is a possibility to use arc G codes (G2 clockwise arc, G3 counterclockwise arc) with Marlin to reduce the number of G codes needed to print circular objects, but the only program that even tries to generate these G codes is Slic3r, and that is only an "experimental feature".
Why? Because it's a hard problem to reconstruct the original mathematical shapes that created the STL file. A long time ago, my professor said "You should always tell downstream programs what to do, not have them try and figure it out." That has proved out to be true time and time again. This means the instructions to the slicing code should be as rich and explicit as possible, rather than have the slicing code try to figure out what the intent is.
Certainly, eventually, there will be technology to reconstruct solid models out of STL files, but like colorizing black and white movies, or performing raster to vector conversion, the result is never as good as having the original data.
Why are we throwing out the information that can make 3D printing simpler? Why not start making color movies today and create (or adopt) a real 3D format for the use-case of printing designed (rather than scanned) objects?
The problem is, there are many formats (e.g. IGES, STEP, etc.), and figuring out which one would be best for the 3D printer community is also a hard problem.

Success with Cyanoacrylate

Cyanoacrylate "crazy glue".

Based on an Ultimaker Google Group post and Florian's comment on my ABS warping post, I went out in search of some cyanoacrylate to try and glue the first layer to the platform in order to avoid the warping when using ABS.
I located some glue that is mostly cyanoacrylate in the local hardware store. I sprung for the big 10g bottle of this "crazy glue", even though in my experience it dries up long before it gets used up.
The first problem is that this trick involves applying the glue to the corners of the print "while printing [the] first layer". If you've ever seen one of these Ultimaker machines run a small part, you'll realize there are two issues with that. The first is that the layer takes about 15 seconds to print, which isn't much time to futz around gluing the corners. The second issue is that if you get your fingers in the way of the moving head in that small print area you'll either a) hurt your fingers and/or b) shift the print by making the stepper motor skip (it's operating open loop, so it doesn't measure where the head actually is, it just counts steps, so if one or more steps fails to move the head, the location of layers above the skip are displaced).
So what you want is for the machine to stop for you so you can do the needful and then tell it to start printing again. Fortunately there's a code for that.
The G code M0 stops the machine and waits until the user presses the button on the Ulticontroller. If you don't have an Ulticontroller, you can still use it with a timeout via the S parameter.
So the workflow is

• slice the stl file to gcode
• manually edit the gcode file to insert the wait code
• load the file into the printrun program
• start the print
• when it pauses, apply the glue to the corners
• press the continue button (or let the wait timeout)
• continue the print

So, where do you insert the G code when you edit the file? Here's the first few lines of the part G code file.

;TYPE:CUSTOM
M92 E854.177692541
G21        ;metric values
G90        ;absolute positioning
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G92 X0 Y0 Z0 E0 ;reset software position to front/left/z=0.0
G1 Z15.0 F400
G92 E0         ;zero the extruded length
G1 F75 E5
G1 E4.5
G92 E0         ;zero the extruded length again
G1 X100.0 Y100.0 F3500
G1 Z0.0 F400
G90 ;set positioning to absolute
G21 ;set units to millimeters
M105
M106
M113 S1.0
M108 S25.0
;TYPE:SKIRT
G1 X57.35 Y111.134 Z0.1 F9000.0
G1 F2400.0
G1 E1.035
G1 F9000.0
G1 X63.234 Y117.017 Z0.1 F1500.0 E1.0935
G1 X138.734 Y115.05 E1.6242
G1 X142.65 Y111.134 E1.6631
G1 X142.65 Y88.866 E1.8196
G1 X138.724 Y84.941 E1.8586
G1 X61.285 Y84.932 E2.4028
G1 X57.35 Y88.866 E2.4419
G1 X57.35 Y111.134 E2.5984
G1 F2400.0
G1 E1.5984
G1 F1500.0
;TYPE:WALL-OUTER
G1 X64.15 Y91.75 Z0.1 F4500.0
G1 F2400.0
G1 E2.6334
G1 F4500.0
G1 X71.25 Y91.75 Z0.1 F1500.0 E2.6833
G1 X71.25 Y93.85 E2.698
G1 X66.25 Y93.85 E2.7332
G1 X66.25 Y106.15 E2.8196
G1 X126.65 Y106.15 E3.2441
G1 X126.65 Y93.85 E3.3305
G1 X121.65 Y93.85 E3.3656
G1 X121.65 Y91.75 E3.3804
G1 X135.85 Y91.75 E3.4802
G1 X135.85 Y108.25 E3.5961
G1 X64.15 Y108.25 E4.1
G1 X64.15 Y91.75 E4.2159
G1 F2400.0
G1 E3.2159
G1 F1500.0
M0 S30 ; wait to apply glue
;TYPE:WALL-OUTER
G1 X128.65 Y94.15 Z0.1 F4500.0
G1 F2400.0
G1 E4.2509
G1 F4500.0
G1 X128.65 Y105.75 Z0.1 F1500.0 E4.3324
G1 X133.85 Y105.75 E4.369
G1 X133.85 Y94.15 E4.4505
G1 X128.65 Y94.15 E4.487
;TYPE:WALL-INNER
G1 X128.65 Y93.75 F4500.0
G1 X128.25 Y93.75 F1500.0 E4.4899
G1 X128.25 Y106.15 E4.577
G1 X134.25 Y106.15 E4.6192
G1 X134.25 Y93.75 E4.7063
G1 X128.65 Y93.75 E4.7456
G1 F2400.0
G1 E4.1456
G1 F1500.0
;TYPE:WALL-INNER


Too much glue, 2nd layer separates.

The location I used was after the first TYPE:WALL-OUTER that defines the corners (see the line in yellow), right after the extrusion retraction preparing for the jump to the second outer wall. This should leave less of a blob.
The first time I did it I applied too much glue and the second layer was pretty much mush, so it separated from the first layer.
The second time I was more careful, and used a Q-Tip to smear the drops of glue out a bit. I also increased the extrusion temperature from my normal 230°C to 240°C to get the second layer to stick to the (now colder) first layer.
I also turned off the cooling fan by unplugging it at the extrusion head. There's a code for that too (M107, fan off), but this didn't work for me. Something to investigate later.
This yields the desired result, although now, the blue tape is starting to lift from the print bed, so the print was still distorted a bit.

Successful attempt, although the blue tape is lifting at the corners.

You can't really see the tape lifting in the picture, but the hole is supposed to be round (naturally).
Before the print, I did do the best I could to make the tape adhere to the bed. If you shine a light from below the acrylic and you run your fingernail backwards over the tape if the tape isn't pressed down completely you can see a mark where your finger nail presses the tape fully into the bed.
The slight curvature can maybe be seen better when the part is removed from the printer.

Only slightly warped part.

Still, it's good enough.
You can see the part on Thingiverse.

ABS Warping

The two types of plastic commonly used in 3D printing are PLA and ABS. PLA is more brittle and hence a little less strong than ABS, which is what LEGO bricks are made of. Working with ABS, however, has a few more issues than PLA.
The biggest issue is the thermal contraction of the plastic after extrusion. As an example, consider the part shown here (a SmartPhone tripod mount).

Printing with PLA is no problem, but printing with ABS yields a part that is curved like a banana. The photo shows the PLA part (back) and the ABS part (front).

You can see that the plastic on the bottom layers has separated from the printing platform due to the stress of the cooling plastic in the layers above it. It's the same reason that leaves curl up when they dry out. There are a number of ways suggested to fight warping and curling. Most sites suggest a heated bed, which is an extra cost, non-standard item for the Ultimaker. Maybe later.

I first wanted to try design with mouse ears. This only works if you have the source file and not just the STL file so you can manipulate the solid model. This is one of my pet peeves with Thingiverse, most things only have the STL files. I predict that in 3 years, Thingiverse will be considered a junk yard and obsoleted by a site that requires solid models. But I digress.

Adding small ears to the part, and it looks like this.

This only ameliorates the problem. The part edges still lift from the bed while printing.

Oh well. Back to PLA I think.

Retract Calibration

Besides putting plastic where you want, the other half of the 3D printing problem is avoiding putting plastic where you don't. This is easy for large, potato shaped objects, but when you want to create fine features at the resolution of the machine you need to pay close attention to settings that affect voids.
I know of at least three modules in the Skeinforge module chain that attempt to address this problem, but there are probably more. The one that comes out-of-the-box is called comb. From what I understand so far, comb works by moving the extruder over already printed parts as much as possible rather than moving the extruder over a void which would leave a thread of filament dangling. This only works to an extent since often there's no place to hide.
To illustrate, I've created a fine featured part similar to the 0.5mm Thin Wall Box. It looks like this.

Castellated 0.5mm Thin Wall Box

The dimensions are 20mm on a side, 5mm high and the walls are 0.5mm thick. The slots are 2, 4, 6, and 8mm wide and 4mm deep. This is what the part looks like when using comb and with comb off beside the normal thin wall box.

With and Without Comb

As you can see comparing the walls, comb messes up the extruded areas in addition to cleaning up the void areas. Another module in the module chain that tries to fix the problem is called oozebane. From its description oozebane turns off the extruder before crossing a void and turns it on before resuming. The oozebane module is not turned on or exposed by the Cura software.

The module that is exposed in Cura is dimension. The dimension module converts the simple extruder on/off codes (the obsolete M101 and M103 codes), that are carried through the module chain up to that point, into the E 'dimension' values passed to the firmware. This relieves the firmware of calculating the extruder motor distances using the travel distances which involves compute intensive square root operations that the little microprocessor really doesn't have time for. It also provides a way to manipulate the extruder 'E' commands to retract filament when passing into a void by reversing the extruder motor - ostensibly to suck molten plastic back into the extruder, but more likely just to remove the latent pressure in the melt chamber. When starting extrusion on the other side of the void, it adds 'E' to perform a catch-up by advancing the filament back to where it was before the void.

The knobs you get to play with in ReplicatorG and Cura are a subset of the parameters available for the dimension module, but include the basic ones:

Dimension Parameters in ReplicatorG and Cura

What I need to find out is valid, or hopefully optimum, values for the four Cura parameters (on the right).

• Minimum travel (mm) - the length of void path that has to be present before using retraction when jumping the void. This is not exposed in the UI of ReplicatorG.
• Speed (mm/sec) - the speed of the extruder motor when doing the retraction and subsequent catch-up to start extruding again. This corresponds to Extruder Retraction Speed (mm/s).
• Distance (mm) - the amount of filament to draw back and catch-up when doing a retraction. This corresponds to Retraction Distance (millimeters).
• Extra length on start (mm) - the amount of extra filament to extrude when doing the catch-up. This corresponds to Restart Extra Distance (millimeters).

But first, I need a good test case. Part of the reason that comb-off print looks as bad as it does for this example is because there is a prior module called inset that behaves badly with small features. It's algorithm works well for large areas, but small features drive it nuts. The algorithm has two phases, one that does the actual insetting, and another that tries to simplify extrude paths that lie basically on top of one another. It works well for the thin wall box, but not so well for the castellated version. Here is a picture of what it does.

Inset Algorithm.

By way of explanation, the image is of just one corner of the castellated box on a layer above 1mm, so the inset is a 1mm wide rounded corner L shaped polygon (0.5mm wall thickness less 0.2mm of inset on both sides = 0.1mm) down the center. Overlayed on top of that are the algorithmically "widened" edges in two flavours - narrow diamond shapes and thicker hexagonal shapes. As it processes the polygon edge by edge, subsequent segments running through these "widened" areas are removed - identified in red. This leaves the magenta segments to be printed - which is a problem. The problem is well illustrated by the (excellent) GCode viewer built into Cura, as the mess on the left.

Before and After GCode using Cura

The red lines are extruding, and the blue lines are move operations. As you can see the extrude paths remaining after the inset algorithm finishes leave no choice but for large numbers of void jumps to and from the corners (where the magenta paths start and end).
One of the huge benefits of open source software is the ability to go in and fix a problem. It's also one of the drawbacks, because it can be an incredible time sink. After quite a while of looking into the code, I eventually gave up trying to fix it and wrote my own module. The result is shown on the right.

So, on to the calibration.

Varying the retraction distance first, I observed that only with retraction distances greater than 0.4mm or so did the small 2mm slot start to open up. I think this is because of the hysteresis built into the system with the filament rattling around a bit in the Bowden tube, compression of the filament, gear backlash in the extruder, etc.

Retract 0.4mm distance, 0 extra, 13.5mm/sec speed, 0.1mm layers, PLA, 200°C, 25mm/sec feedrate

There is also a noticeable thickening of the wall before and after the void where the extruder pauses to retract and catch-up. This may be able to be fixed if the firmware can handle changes to the extruder while travelling so that the retraction can begin before the movement finishes.

There are also diagonal sprue like artifacts that grow where the plastic snot rubs off in mid void. These are very weak and may pose no problem other than having to be cleaned up manually.

The wall thickness is also reduced from 0.48mm to 0.30mm, which indicates the extrudate isn't catching up after the void.

Varying the retraction speed has surprisingly little effect, other than to make the print speed slower or faster, so I recommend making it as fast as the extruder will allow, say 40mm/sec - since the maximum speed is 45mm/sec according to the firmware.

Increasing the extra length parameter causes the wall thickness to increase back to the nominal thickness (as for the thin wall box without the slots) with only a very small value, e.g. 0.025mm at a retraction distance of 0.6mm and 0.035mm at a retraction distance of 1.0mm.

So it seems the parameters I'll use in the future are:

• Minimum travel (mm) - 1.0mm (default).
• Speed (mm/sec) - 40mm/sec (maximum).
• Distance (mm) - 1.0mm (to remove hysteresis).
• Extra length on start (mm) - 0.035mm.

Retract  0.8, 0.9 and 1.0mm distance, 0.035 extra, 40mm/sec retract speed, 0.1mm layers, PLA, 200°C, 25mm/sec feedrate

This is still not ideal, but I think it's better than it was.

Cura

I've been struggling for a while (besides being out of town) with the open source ReplicatorG software used in conjunction with the Marlin/Sprinter firmware. It seems that there isn't a fork of ReplicatorG being maintained for the Ultimaker community, so if you choose that route (as opposed to buying software like Nettfab) you are pretty much on your own.

Now admittedly, a lot of the time was spent trying to understand the new open source development paradigm around Git and Github, but my progress was almost zero and I was getting pretty down-hearted.

Then I saw Florian's post about Cura and leaped on it. I'm glad to say the results were quite good.

I was a bit put off by a disconnect between the E (extruder axis) scale and the usual Marlin/Sprinter scale.
From what I understand, the E axis had always in the past been the amount of "filament", i.e. 2.9mm diameter input to the extruder. Then somebody in the Marlin/Sprinter group decided that wasn't correct - I don't know who - and started defining the E value as the amount of "extruded" plastic, i.e. 0.4mm diameter hot output from the extruder.

Obviously there's a ratio of 50 between the areas of the filament and the extrusion, so if you aren't careful, your slicer will generate G code that will drive the extruder too hard (and back up plastic into the Bowden tube, see Nozzle cleaning) or have nothing being extruded at all.

To get the firmware and the slicer to agree, Cura makes a custom firmware based on the Marlin/Sprinter source. It's important to use the Cura feature that updates the Ultimaker firmware. And then the generated G code has E extrusion values in the old fractional values and uses a calibrating M92 code to set the steps per unit of E (for me it was calibrated at 848.17073123).

The really annoying thing is these calibrated values are not stored in the profile.ini file for the program, but some secret as-yet-undiscovered location.

Nozzle Cleaning

After twice backing up plastic into the Bowden tube, and discovering I could no longer push plastic through a hot nozzle by hand, I finally had to admit that the extruder nozzle was completely blocked.
So, here's what I did to unclog it.
First, remove the brass tube and nozzle from the extruder head. This means dissembling the head, removing the PEEK insulator and then using a wrench to unscrew the nozzle and tube from the aluminum block containing the heater.
I tried to separate the 6mm brass threaded rod from the nozzle, but stopped after mangling the threads in the vice - brass is really soft and no matter what you wrap the threads with, it isn't soft enough to not damage the threads and yet stiff enough to hold it fast.

The nozzle is finally clear.

Next put the tube and nozzle combo into the oven and turn the oven to the hottest it will go. In the winter here it might have gotten to 250°C. I used a bent paper clip arrangement with one end stuck up the tube to hold it so that the nozzle is pointing up, but in hindsight I think that a better way would be to not have anything stuck up the tube at all. After 15 minutes or so at that temperature, this leaves a small puddle of caramelized plastic on the protective foil on the pan under it.
Then use a bath of acetone and a Pasteur pipette to bathe the interior and exterior. You need to mechanically clear the blockage. There are very few things that will poke into a 0.5mm hole. A pin or needle is too large after the first millimeter.I finally settled on the ink plunger from an old Staedtler Mars mechanical pen I had. If you take it apart, the 0.5mm pen has a fairly stiff wire about 15mm long that one can stick into the nozzle hole.
You can't imagine the relief when the wire can finally fully enter the nozzle.
Keep cleaning with the wire from the nozzle side and a long pin from the tube side until the nozzle is clear.
You can switch to a bath of vinegar and salt (home made brass cleaner) to clean up the rest until the black crud stops coming out. Acetone is too volatile and won't dissolve the burnt stuff very well. I think if I was in North America, I might try oven cleaner.
Finally, run a 6mm x 1mm metric die over the threads to clean them up after the mauling they got.

By the way, to get plastic out of a Bowden tube is not so easy either. You have to squirt acetone into the tube end, bend the tube back and forth (as much as you can) and pick at the blockage with a pin and poke at it from behind with the 3mm plastic stock, until the wad is removed.