Stepper Motor Indexer & Decoder
ECE 476: Spring 2005

Daniel Beer, dbb28
Tony Lloyd, aml54
 

Introduction | High Level | Hardware Design | Software Design
Results | Pictures | Conclusion | Appendices
 

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.