Experiments in Three Dimensional Motion

How we came up with the idea....

During our class brainstorming, we converged into the notion of building an XYZ stage. This technology is mature, but the idea of making it from surplus components and make shift electronics was intriguing to us. Next, Andrew visited Roger at home and looked over a large surplus XY table that he had in his basement. It was not practical to work on it considering that we had to move the table from home to home, and home to Botfest. Come to find out, Andrew had a good collection of surplus stuff better suited for our project. His collection included motion components, electronics, and necessary tools. In addition, our talents were complementary (in Fred's words). Roger was mechanically savvy and Andrew was electronically/electrically savvy.

Description of what our project does, and how it operates.

Our project consists of designing, building, and controlling an XYZ stage (a stage is also referred to as a "table"). This is a mechanical machine that has X-motion, Y-motion, and Z-motion and can be used in many different applications such as SMT assembly, PCB drilling and milling, 3D engraving, 3D printing, pick-and-place, inspection, scanning, etc. Our task was to find matching parts and components, attach them together, find stepper motors, build motor drivers, and find a way to control the motors. A bare bone XYZ table does nothing but move in 3 axis referencing a Cartesian coordinate system. The table can have different motion architectural design. For instance, a gantry design is when the workpiece is stationary and have the X, Y, and Z axis move. Our design, however, the workpiece will be moving in X and Y, and the end-effector will be moving in the Z axis. Our table can travel 4 inches in each axis. Therefore, a workpiece can be as big as a 4 x 4 x 4 inch cube. Controlling the table was challenging for us because of time constraint. We ended up using a computer and using parallel port interface. Time did not permit us to design and build end-effector, however, this is our goal for project II.

Above is a cad rendering of our project that Roger made to visualize how the parts would fit together. For more cad drawings, look here.

Subsystems:

The major components of the motor control system are shown in the block diagram. Each motor is attached to a four channel power driver board. This allows for isolated logic level inputs, and high current outputs to drive the windings on the motors. Each power driver board is attached to a Parallel I/O board, consisting mainly of an 8255 parallel I/O controller. This allows for up to twenty four output lines from a standard parallel printer port. The Parallel I/O board is then plugged into the printer port of a laptop, which contains the control software to drive the 8255 chip, and sequence the motors. The input pins of the parallel port could be used for the limit switch inputs. All of the electronics in the system (except for the laptop) is powered by a 16 volt, 30 Amp supply.
For more information on each subsystem, click on the parts of the image, or the links below.

Project Sections

Obstacles to further functionality

Actually, the majority of the systems worked reasonably well for a technical demonstration. Murphy let us break the law during Botfest. Problems included:

Limit switches not working, not hooked up, etc. When Roger refurbished the tables (took them all apart and cleaned them all up) he didn't check to see that the limit switches function electrically. We were running short on time, switches seemed to sometimes work, and sometimes not work. During the show I noticed that one of the slides is still damaged, so it cannot slide to its limit. Other switches may need to be replaced. The inputs on the 8255 pio board do seem to work, but we didn't have time to wire them to the actual switches.
This seemed like it would cause a problem for homing the axes. This proved only to be true for the Z. The X & Y we could run against the hard stop to set the table to a known position. The Z table dosn't seem to have a hard stop, so we have some concerns that we might damage something by extending the Z slide to the end of its travel.
High level control dosn't work. We had hoped to have some high level control for the table working so that we could move in complex patterns. The quick thought was to have Eagle dump out some data that we could read, but something is wrong with some of the movement routines, so we didn't have it doing more than moving a single slide at a time back and forth. The parser an axis control routines still need work.
Cables are everywhere. We need to package all of the loose cables and boards up so that everything fits together the way it should.

Plan to get it working

The remaining debugging tasks should be straight forward.

Debug switches.
Finish and debug parser and driver software (sitting down, and spending some quality time with the debugger should be a big help here.)
Finnish up packaging issues.
Design and build next phase. (End effectors)

Particular Contributions

Roger -- most of the mechanical design, implementation, wiring, some high level software to draw circles, helix, etc. Roger built his first power supply! Lots of electrical and mechanical debugging and assembly. Renderings of the system.
Andrew -- most of the interfacing, some mechanical, PCB's interface circuits, low level code (drivers), web page design, lots of hardware and software debugging.

What we didn't do, what didn't work, etc.

Approaches that didn't work:

Initially we thought that attaching the motor controllers to Logochips connected to the Cricket bus seemed like the way to go. However, there were two problems with this. First, the table was sitting and Andrew's basement along with any spare parts, and the software development tools were sitting up in the lab. Second, we wanted a "quick" way to write some code to do some testing. The quick way to get digital I/O was to use the parallel port on a PC, but in order to run the motors we needed 12 i/o lines for the circuit we were using, plus a few for running what ever we decided the end effector would be.

We needed more I/O. Embedding another microcontroller was quickly entertained, but I couldn't find my development tools for those, quickly either, so we needed another approach. Looking at an old computer design class I took, I remembered the 8255, and did a quick scan of the web to see if anyone else had done something similar. Google's cache seemed to have something in it that suggested that it would be possible, but the code and pages describing it were gone. I pulled the register information out of my old text book, and wired it to the parallel port with the incomplete information. A few days later (not quite quick) I had outputs more-or-less working (although my ports were in a different order than I though) and tried to see if I could use the bi-directional mode of the parallel port to allow me to read from the 8255 also.

This never seemed to work, so I soldered an extra connector to an unused corner of the board, and wired the input leads directly to the printer port. A short script displaying the status of the control registers, and a screw-driver to short pins on my new header suggests that we have five input lines that work.

We looked at some of the public domain packages for interfacing CAD to steppers, but they all seemed to require a step and direction interface, Rather than our unipolar motor phase interface. Not sure what we were going to use for high level drive software, we went to class. In class Fred presented his method for getting drill patterns out of Eagle, and that suggested again, that writing a parser to take an output from Eagle might not be too hard. Unfortunately, we didn't have time to get something working by Botfest. To the public it didn't seem to matter too much, they were more amused that it was moving, and less interested in what pattern it was moving in.