Microscopic

My eyes aren't so good anymore, so I have a head mounted magnifier that I got from Lee Valley some years ago. But for the current work I'm doing, I needed to get even more magnification. It turned out to be surprisingly easy.

I remember reading that by reversing the lens in a webcam, you can make a USB microscope. I had an old Logitech webcam lying around since my new laptop has an integrated one, and there's instructions on Instructables.

It took about 10 minutes before I was seeing stuff in the Quick View panel with the lens bodged on backwards with blue tape.

The trouble is, the position of the camera and specimen need to be micro-adjusted and then held in one position for long periods of time... hey wait a minute I have a X,Y,Z stage with just those properties.

So clamping the "microscope" onto the print head and running PrintRun to position it turns out to be a very good control system to look at your samples (if you turn the printhead fan off). It also shows some other interesting info.

For example, I now realize how much backlash I've got in my axes, because the image from the microscope is exquisitely sensitive to even the smallest motion. So how many times do you need to touch the 0.1mm step button in one direction to see motion after taking a 1mm step in the other direction. This I'll need to experiment with, so more on that later.

But I did find out what I wanted to find out - the two traces I was laying down were not touching. I'm guessing at the numbers here, but I think the magnification is about 300 times in the picture below, and the PLA trace running diagonally up from left to right (it looks like icing that's been scraped with a spatula) is about 0.35mm wide and is separated from the next trace in the lower right hand corner by 0.13mm.

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.