Stepper Motor Indexer & Decoder
ECE 476: Spring 2005

Daniel Beer, dbb28
Tony Lloyd, aml54

5. Results

5.1 Speed

Our design is very responsive to both user input and external
conditions. There are no noticeable delays between a control message and
an action, nor between an external change, such as a limit switch being
flipped, and the device responding to it. Input messages are processed
instantly and a return value returned.

5.2 Accuracy

The motor controller is accurate to the microstep as validated by the
optical encoder. Since the encoder is connected directly to the motor
shaft, it is guaranteed to catch every step. Inputs to the motor are
accurate to the millimeter.

5.3 Safety in the Design

We use both hardware and software limits to prevent damage to the
motor, electronics and user. The motor position is limited by software
limits set by the user and hardware switches that are placed at either end
of the motor. The speed of the motor is limited to 5000 hz, keeping it
creating resonances and damaging the load. Finally, all our digital
components are opto-isolated, preventing damage to them from motor
transients.

5.4 Interference with Other People’s Designs

Motor controllers and microsteppers in particular are notorious sources
of noise, both conducted and radiated. We used ferrite bead inductances to
try and protect the MCU as well as an opto-isolator on the enable/disable
line. How susceptible our design is to its own emissions is not known at
this point, but it could possibly create radio waves that could interfere
with other projects.

5.5 Usability of Our Project

Our motor controllers would have direct commercial applications if it
were to prove to be a hardenable design. There is nothing worse that a
nuisance design that always gives people trouble and the only way this
could be known is through lengthy testing.

We designed our project for use in the CHESS labs in Cornell University.
The finished project is featured and accurate enough, and could be used in
the lab with only minor modifications.

5.6 Problems, Resolved and Outstanding

The LS7266R1 counter has increased its set-up and hold times from 50 to
80 nanoseconds over the past 5 years and the timing diagram are not what
you would expect, say on a memory chip. We think we have resolved any
problems by inserting nops (no operation) in the read and write code.
However, the chip has been observed to not respond. This is a very open
question. The set-up and hold times for the ATmega32 port pins doesn’t
seem to be in the manual? The problem is outstanding.

By holding the reset button down we could drive the motor. We had to gate
these signal OFF. We observed other port pins on the ATmega32 while the
reset button was held down and they are very active; the opposite of what
was expected. This problem has been resolved.

The biggest problem we had was with the limit switches. We inserted an
74LS74 debouce circuit in a vain attempt to debounce the limits while
backing off the limit. We were not successful nor have I ever seen a
system which doesn’t take multiple attempts to back off a limit. The
problem is outstanding and may be resolved with software.

We had problems getting the RS-485 to run because the Superlogics 8520
RS-232 to RS-485 converter seems to be none compliant with regards to the
120 ohm termination requirement in RS-485. The system works well with no
termination. We resolved the termination problem by using a circuit
commonly seen in RS-422, a capacitor in series with the termination
resistor.