Diagnosing and fixing a misbehaving axis

Here's a story about a learning experience I had with my CNC3040 router. I'm documenting it here in the hope it helps someone else avoid my mistakes.

One day, in the middle of a light routing job, the X axis suddenly went crazy. It started stuttering and wandering about and generally doing anything else than what it was supposed to do. My first thought was that the driver board had fried. After all, that is something cheap Chinese drivers are known to do. A simple test seemed to confirm my hypothesis. I swapped X and Y axis cables and drove the axis back and forth a little and it seemed to work fine. (Mistake #1: I didn't test the axis at different speeds and accelerations)

So I logged on to eBay and ordered a replacement driver for $10. Once it arrived and I finally got around to replacing it, the axis continued to misbehave. I tested the axes more thoroughly this time and, indeed, the X axis didn't work right with any driver of other drivers either. Frustrated that I had replaced a perfectly good driver (at least now I have a spare), I decided the problem must be in the stepper motor. The erratic behavior (stuttering, random direction changes) seemed consistent with a burnt out phase. So it was back to eBay and ordering a new motor. (Mistake #2: jumping to conclusions without testing. Again.)

You can probably guess what happened when I got the new motor. Nope, it didn't fix the problem. So the problem couldn't be in the computer's parallel port, the breakout board or the drivers and now I had checked that the old motor actually worked fine when connected to the other axes. So what's the only thing left? The wiring. A multimeter revealed that one of the four wires in the stepper power cable was broken. After replacing the cable, the machine worked like new again.

In the end, the whole ordeal was cased by me thinking the wiring was the least likeliest part to fail and not testing that at the beginning. On the plus side, I now have an extra motor and an extra driver, so maybe I'll get around to building that 4th axis someday.

KQueryBrowser

I'm on roll. Just pushed my latest project, KQueryBrowser, to github. KQB is a database query tool for KDE that uses qt-webkit to format the query results nicely. And yes, I know the name is highly unoriginal and follows that annoying K<something> pattern, but at least it's descriptive.

The motivation for this yet another query tool was simply that I did not like any of the other query tools. The command like clients are nice, but awkward when browsing through very large tables. MySQL query browser was great, but was replaced by MySQL Workbench, which is way too cumbersome when I just want to run some SELECTs. Pgadmin suffers from the same problem. And most of the graphical tools use GTK, which makes them look ugly or (in the case of MySQL workbench) simply broken on KDE.

So here's KQB. Looks pretty on KDE, works with multiple databases and lets you get straight to writing queries.

Piqs

I just created a new repository on github for yet another hobby project I've been working on: piqs. It's a lightweight image gallery program with advanced tagging capabilities.

It's an experiment in alternative categorization; rather than sorting images into albums/folders, they are all shown in a single flat view, but that view can be filtered with tag queries. Of course, lots of gallery software have tagging capabilities nowadays, but piqs takes it a bit further. You can set up tag aliases and implication rules and something I don't think I've seen elsewhere: tag namespaces. For example, the tag string "[cat, orange], [dog, yellow], backyard" might be applied to a photo of an orange cat and a black dog taken in the backyard. The search string "cat, orange" will return all pictures with a cat and something orange, but the more specific "[cat, orange]" will return pictures of orange cats only. Further, boolean operators are supported: "cat, !dog" will return pictures with cats, but not dogs. "cat, (!dog|[dog,black])" will return pictures with cats and no dogs, unless the dog is black.

This sort of tagging only really starts to pay off once the image collection starts getting very large, so I've tried to design piqs to support huge galleries. So far, I've tried it with about 50000 untagged images and it hasn't choked yet. To help tag every image comprehensively, piqs can infer new tags based on a set of rules. E.g. the rules "cat --> mammal, carnivore", "mammal --> animal" will automatically add the tags "animal", "carnivore" and "mammal" to a picture tagged with "cat".

Limit switches, part 2

In the previous post, I showed how I added limit switch inputs to my CNC driver box. Now its time to attach the actual switches to the machine.

Limit switches, part 1

The CNC3040 machine doesn't come with limit switches and having already crashed the machine once I thought it was high time to add ones. The problem is that the driver box doesn't have inputs for the switches. My first idea was to build a passthrough box to break out the input pins, but peeking inside the case I found a nicer solution.

Griffin powermate + EMC2

I'm currently designing a physical control panel for use with EMC2 and for that I needed to learn how to use the HAL. HAL is EMC's hardware abstraction layer that provides a sort of virtual breadboard for connecting components, both hardware and software, together. One great thing about it is that it's really easy to write your own userspace HAL components in python. A short tutorial from EMC's documentation shows how. Also, Just Milling Around has a great tutorial on how to interface an Arduino with EMC using a python script.

As an exercise before getting started with my control panel, I decided to write a driver script for a piece of hardware I already have: A powermate jog wheel. My script creates two HAL pins: An output pin that can be connected to axis.N.jog-counts and a boolean input pin to turn the LED on and off.

The powermate HAL script is available here: powermate.py

Improved image carving

JGCGen now has better support for image carving. Since the previous post, I've added two major features. The first is a roughing strategy for removing lots of material fast and in multiple passes so you can carve deeper. The second is the decoupling of image resolution from carving resolution. Stepover distance can now be smaller than a single pixel and jgcgen will interpolate the values in between. Another important change was a rather embarrassing bug fix: the tool shape profiles for flat and ballnose endmills were swapped! No wonder the previous test looked flatter than I expected...

Still on the TODO list: optimize rough path generation to minimize rapids and implement a waterline strategy.