One of the goals for an effective setup is to automate taking pictures of the dies. Current technique is to manually move the chip around while snapping pictures. As the chips get large, technology shrinks, etc, it becomes increasingly desirable to get more precise and automated control. The plan: use EMC2 controlling some linear stages and gphoto2 controlling a Canon SD100 to scan across a die to be assembled by Hugin.
The control system doesn't necessarily have to be EMC2. In fact, I've heard people have difficulty using it outside of the GUI. So, I might just use raw outp() calls to pulse a parallel port as needed to control the stepper drivers. I have some old Precision Motion Control drivers that can just barely be seen to the right in this image. The motors I'm using are fairly small, but the drivers are current limited, so it might work out. Otherwise, I'll make up a transistor based driver which shouldn't take too long. On the same note, I might end up using that stage setup if I want to scan some larger images later under high precision. I have a few other things I need to get detailed images of that are much larger.
The original plan to control the stepper motors was to couple them with springs to the stages. Something like this:
However, in early testing before even mounting things, I realized that they would build up enough force to overcome the static friction, but the stored energy in the spring would cause a large movement. Higher spring constants would only lead to the stiffness problems I was trying to avoid in the first place, so this solution was a no go.
Here is the current attempt at linear motion control:
It uses two stepper motors with longish gears to overcome issues from the micrometer moving in and out as turned. The Y axis (one on right) will be slightly trickier as the gear will move back and forth as the X axis is actuated. To overcome this, I'm going to try to put a spring force on it. With the small distances being moved, it shouldn't move enough to become a problem.
My luck with libgphoto2 has been mixed so far. It tends to get into internal error states fairly easily. Also, I've had difficulty building it to get the latest version. I tried to use a VM which could get a better version, but still same issues. In particular, I need to disable the flash, but this results in internal errors. Since I really need this, I'll probably put in the effort to get the newest version working and/or get in contact with the libgphoto2 team to help develop a patch to fix w/e the error is. This is an issue because it severely lowers the exposure time, resulting in bad pictures despite my relatively bright levels of light. I got this camera because gphoto claimed very good support for it and they were available on eBay at quite a reasonable price ($15 + S/H for used units, maybe $40 + S/H for newish units). I bought a SD110 originally, but it turned out to be much worse condition than the seller claimed, but since it was so inexpensive I didn't find it worth the effort to pursue. I found a SD100 buy it now for $15 without charger and get a good condition one for around $40. So all in all, I have a SD110 for parts and two SD100s. This has been quite good as the major complaint of the units is their relatively short battery life. With a spare battery or two, I can let one charge while I use the unit, which leads to good usage. The batteries tend to charge faster than then are drained.
My experience with Hugin has also been mixed. Under Linux, when I try to stitch together pictures, it crashes. I tried to use it under Windows to stitch together some of my dies, but they ended up coming out more like pretzels than beautiful images. In theory, use of the stages will make this process much easier as the images should be able to be precision aligned to each other.
Thanks to Robert Reeve for helping me with the design of this stage setup and for fitting the gears on the ends of the micrometers! Also, thanks to Jim Schatz for letting me borrow the microscope!