The process in detail:

CAD -- Computer Assisted Design

  1. create model (2 or 3D) using vector-based software
  2. visualize the piece using rendering software (optional)
  3. save the image information as a tool path (plot-file)

CAM -- Computer Assisted Manufacturing

  1. load tool path file into CAM platform
  2. CAM software controls flow of tool path data to motor and solenoid drives
  3. custom mechanics convert motor shaft rotation into desired tool motion

Model Design:

For the sake of simplicity, I will use the 2-dimensional case in my discussion. There are several drawing programs available (CorelDRAW, Adobe Illustrator, DesignCAD, AutoCAD, etc.) which allow the artist to create vector-based representations of images/objects. The distinction here, is between drawing and paint programs.

After the desired image is created using the best hardware and software available to the artist, the information must be saved in a form readily "understandable" to the robotic tool. For this purpose I use HPGL (Hewlett Packard Graphics Language), because it is well supported, and easy to understand. It was developed for pen plotters, and most drawing packages (and all CAD software) will output files in this format. The essence of this format is: "go from this x,y coordinate to that x,y coord., with the pen either up or down." I use an inexpensive HP7475 plotter to "proof" my tool path output, before taking it down to the CAM platforms in the studio.

The CAM platform:

I have settled on IBM-compatibles as my work-horses for the studio. My reasons are many, but boil down to three: they're cheap, well supported, and they talk to my design computer. The requirements are meagre: 512K RAM, one floppy (no HD) and a mono monitor. ~$50 for an XT, and $75 for an AT. Since the environment is harsh, it's nice to know that replacing them is relatively painless. Over the years, I have written my own CAM software and am willing to share it (just ask-- nothing fancy, but it works). There is a shareware package called DANCAM (contact Dan Hudgins, 466 Diamond St., San Francisco, CA 94114), but I have no experience with it.

From the PC, the information must get to the motor drives-- I use the parallel port. My custom interface requires soldering together a few logic and buffer IC's, but is straight forward and reliable. For a wealth of technical info on the parallel port (and lots of other electronic stuff), check out the FTP site: ftp.armory.com /pub/user/rstevew and get "ibmlpt.faq" and "krislpt.faq."

Why stepper motors?

There are essentially two ways to skin the motion control cat: steppers and servos. I chose the former for my usual reasons-- they're cheaper and easier. While it is true that high-end systems use servos, I believe steppers and the technical expertise to control them are more readily obtained by the garage-roboticist. I have accumulated a fair amount of practical know-how in dealing with these beasts. For a good place to start, I recommend the file "steppers.tut" found at the FTP site mentioned above. I no longer build my own drivers, but the schematic of the one I built during my first experiments is essentially the same as the one I later found in The Robot Builder's Bonanza by McComb. It's crude, but is a good place to start. The motor I used with it was a small 12V stepper that lives in floppy drives-- widely available in surplus electronics shops for ~$5.[driver schematic], (640x480 GIF-7K).
home