Saturday, April 12, 2008

The Etching Calculator [EDIT]

A lot of things, many of them new to me, went into this project. We have "regular" programming, "device" programming, a communication protocol, stepper motor control, motor mounting, power supply design and the mathematics of drawing an optimal line on a pixelated display. Some comments on each.


I originally thought this was going to be the hardest part. "The rest is just sitting at my computer desk and either typing or handling tiny pieces of electronics" was my opinion. In fact, I just cut a couple spacers and then improvised mounting plates from....I don't know what that stuff is. It's like countertop covering. In any case, this part took maybe 45 minutes. It helps that one vital component of the mount is masking tape.

Connecting the steppers to the knobs went through some iterations. The motors had gears on the ends, but of course the EAS isn't geared. I tried various ways of coupling one to the other, but wasn't satisfied. (This turned out to be a power supply problem, which I talk about below, but I didn't know that at the time.) In the end I managed to remove the gears--they are just press fit, so you can knock them off with a nailset and a hammer. The shafts of both motors and the EAS were almost all the same size, which in turn was just a tiny bit bigger than the internal diameter of some plastic tubing. I just cut a short length as a sleeve and voila.

Stepper Motor Control

Physical Computing was invaluable. In fact, reading about how to control a stepper was what gave me the original idea of controlling an EAS1. (The guts of that section are online.) I originally tried to do the entire thing with totally generic components, i.e. plain transistors, but I soon gave that up. I unbent enough to use 2 dual H-bridges. Still generic, but you can't get them at Radio Shack (but what CAN you get at Radio Shack?). This compacts the wiring and anyway the motors need more current than a regular transistor can switch.

If this were a real product, I would definitely build/buy a stepper control board. Finer control isn't an issue, but sweet mother of crap this thing is loud. I think a board can ramp the amperage up and down to give a smoother movement that won't shake the house down.

"Device" Programming

The Arduino libraries include an object-oriented Stepper control library, but it wasn't really suited to what I was doing. The most basic fact it cared about was the RPM. The most basic fact I cared about was how many steps to take. So I wrote my own SingleStepper library. That makes me sound alphanerdy, but seriously, it was just a matter of copying and tweaking the existing library.

Another reason for writing my own was that the Stepper lib left the current on even when the motor wasn't turning. That's great if you need the torque to stay on, but non-great if you have a limited budget of amperage. So my library also turns the power on only long enough to move the motor, then turns it back off.

Communication Protocol

The stock Arduino serial comm library only supports reading a byte at a time. WTF ARDUINO ? Naturally I need to send coordinates larger than 255. The solution is conceptually not too difficult: Send a two-byte int a byte at a time and reassemble on the other end. This actually took a couple days to implement, though, because Python (on the other end of the wire) isn't geared towards working with binary data and then there's the question of negative numbers, twos complement, endianness, etc.

Also, in the case where a lot of coordinates are being generated very quickly, the internal buffer can overflow and the EAS goes haywire. So each coordinate has to be ACKed by the controller before the next is sent.

Line Drawing

Here's another place where I didn't go 100% from my own bootstraps. I actually did start deriving this myself, but soon realized that there were going to be special cases and stuff and I wasn't interested in debugging those. Instead, I just adapted a classic algorithm. I didn't use any of the optimizations on that page, since they are more for a digital display than position control. I did make one optimization of my own, though, which was to not move each motor a single step at a time if I could take 5 steps with one and then 1 with the other.

Theoretically, one could turn both motors on at the same time but at different rates to draw diagonal lines. But even if I had the electric power to do that it's just too hard to attempt.

"Regular" Programming

This is so dead simple that it's really not that interesting, but just for completeness: Generate a series of coordinates (either by hand typing in your own or using some equation) and send them out the serial port.

Actually, I should explain that a bit. I chose to implement this as a display-like device. You give it a coordinate pair X,Y and it moves there. The Arduino handles everything after being handed the values. So for instance the sine wave is being calculated as a series of points in Python on my computer and then sent over to the microcontroller for plotting.

Power Supply

Of these all, the one that I figured out last was the power. The EAS isn't really made with computer control in mind. The controls are surprisingly sticky. At first I thought the coupling between motor and EAS was slipping, but I eventually eliminated that. The power supply I bought is rated up to 1.5A, but only puts out 5V, so the motors only drew about 700mA. Turns out that wasn't quite enough to consistently turn the knobs. By bypassing the power supply, I was able to feed 1A directly to each motor (one at a time) and that was enough.

It may still be a little short, though, because I still get the occasional glitch. But I don't have a wall wart that puts out more than an amp at more than 8V.


The steppers I got out of a broken inkjet printer. (I really lucked out on that, I later realized. Two other inkjets I disassembled had steppers but they were tiny.) I already had the mounting stuff and the Arduino, as well as wires, resistors, etc. I had to buy the H-bridges, the power supply, a heatsink and some power resistors. That probably adds up to $20 or $25. But I can and will reuse it all, especially the power supply, which was the most expensive single purchase.

Oh yeah, and I had to buy an EAS. But one of my design goals (as well as an instruction from my seven year old) was to not alter it beyond being used by humans afterwards. So I consider that a capital investment as well.

1Gave me the idea, but I wasn't actually spurred to do anything until I saw the EAS clock. The auto-erase functionality of the clock would be really nice to have, but I'd like to point out that the ability to draw curves is even nicer.

Per request, here's a closeup of a diagonal line. You can't see the "pixels".

That said, you actually can see the "pixels" in some curves. I think that's because of the (mathemetical) stepping involved in going from floating math to integer.


  1. I think it looks even more astonishing (1) in person and (2) after WEEKS AND WEEKS AND WEEKS of "What the HECK?"

  2. Wow, amazing. Any chance you could post some close-ups to show the "pixel" size? It looks pretty smooth, so I was actually surprised that you weren't moving both axes simultaneously at different speeds. Was that a physical limitation of the stickiness of the knobs (nullus) and the power going to the motors?

  3. Sure, I could post a closeup.

    This is more information than you really care about, but it kind of explains why I did it the way I did:

    First, I didn't even think about doing both axes simultaneously. I'm so used to thinking of the axes as independent, it just didn't occur to me.

    Later, I realized it would make a smoother line, but could be hard to accomplish. I mean, I guess figuring out the different rates shouldn't be that hard (although there are all the corner cases and finding a classic algorithm to copy would be harder), but it would require totally reprogramming the controller. Right now, the step() function "blocks", so they'd have to be interrupt driven or something so I could run both at the same time.

    Later, when I realized that power was in short supply, I knew that I couldn't go that direction anyway. I have each motor drawing an amp, which seems to be just barely enough and is the max my supply can provide.

    And in any case, I'm not totally clear that it would work anyway. They are stepper motors, right? Meaning they have an inherent "pixel size" already. I could possibly draw diagonally across a given pixel, but I don't think I can tell one motor to take 5 steps in the time another takes 1. The only speed control I have is how many steps per second, but that's just adjusting the off time, not the on time. I think. If that makes any sense.

  4. Okay, that makes sense. I thought it might be something like that, but I wasn't sure whether "stepper motor" had to do with the way the actual motor itself works or was just how you happened to program them, if that makes sense.

    That was the other question I was going to ask, how did you choose a "pixel" size? But it's just the screen movement corresponding to the radial distance traveled in one motor step, right?


  5. A stepper motor is a motor that turns a fixed distance every time you "pulse" it, roughly speaking. Mine turn 1.8°, which means they take 200 steps to go 360°.

    I don't know about "radial", but basically. The "stylus" moves however far an EAS stylus moves when you turn the knob 1.8°.

    There'll be a closeup video tonight or tomorrow.

  6. Wow, that resolution is pretty amazing. Nicely done.

  7. wow. this is cool. i didn't even know that people and machines did this kind of thing for fun.

  8. Oh yeah, machines are off. the. hook. when you really get to know them with their hair down. You should take some machines out drinking some time. Crazy.