Embedded Systems
Products & Services

Home Services Products Resources About Contact

Javascript is used
on this Web site to
do things like open
pop-up windows
and to prevent
harvesters from
extracting PayPal
account info.

All material on
this Web site is
protected under
United States
and International
copyright law.
[more...]

Liability for your
use of information
on this Web site is
strictly limited.
[more...]

Trademarks used
on this Web site
are the property of
their respective
owners.

Atmel and AVR
are registered
trademarks of
Atmel Corporation.

RF routing on PCB

Vending Machine Motor Control

An industrial inventory management system used motor mechanisms from an existing vending machine product line.  The mechanism was designed to make one complete revolution and then stop (in the original application, discharging one item from a wire spiral).  With over a hundred such motor mechanisms in a single machine, wiring density was an issue, so sensing of the shaft position was via a microswitch wired in series with the motor.  To return the motor to the home position, the control electronics needed to detect the short current interruptions as the microswitch rode over a flat on the geared-down output shaft and flew between its two positions, both of which were wired together to pass current to the motor.

Running the motor continuously and watching the voltage on a small current sense resistor placed in series showed that the current interruption lasted only a few milliseconds.  During almost all of this time, the current was highly unstable, most likely due to a combination of switch bounce and contact arcing.  No specifications for the motor mechanisms or the microswitches were available and the method by which the original system detected the interruption was not documented.  The customer was also in the process of making design changes to the mechanism.  A solution was needed that was very robust, yet simple, inexpensive and quick to implement.

Digital Filters to the Rescue

The control electronics being designed by ECROS Technology required a microcontroller for many reasons.  Rather than trying to detect motor current interruptions in hardware and passing a digital signal to the microcontroller, it was decided to route the voltage across the current sense resistors to the analog-to-digital converter inputs.

An Atmel® ATmega64 microcontroller was used in the prototype.  The ADC was configured in free-running mode so that a conversion would complete every 13 ADC clock cycles.  Using the pre-scaler, the ADC clock was set so that the sampling (conversion) rate was about 9,000 samples per second.  No timer resource was needed.  (For this application, the exact sample rate is not terribly important.)  The ADC was enabled when the motor was running, the first conversion was started and the conversion complete interrupt was enabled.

In the ADC conversion complete interrupt service routine, samples of the motor current were processed by a simple first-order IIR (Infinite Impulse Response) low-pass filter.  Every eighth sample was placed in a circular buffer and the remainder were discarded.  This process of "decimation" reduces the sample rate to a little over 1,000 samples per second, so that only a small number of samples need to be examined when looking for the current interruption.  The ATmega64 was running the ECROS operating system and a task readied by a periodic timer was responsible for extracting samples from the circular buffer and comparing them to a threshold.  When four consecutive samples fell below the current threshold, an interruption was considered to have been detected.

Filter Design and Implementation

Performing Digital Signal Processing in a microcontroller may not leap to everyone's mind as a good solution to a problem.  Doesn't DSP soak up processing power with all those multiplies and adds?  Once you have worked with DSP algorithms for a couple of decades, however, it is possible to pick and choose those that have simple and efficient implementations, even in processors with modest throughput.

A first-order, low-pass IIR filter has one pole and one zero in the Z-plane.  The zero is always at (-1, 0), which is what makes the amplitude response fall away to nothing as the frequency increases.  The pole is somewhere on the positive real axis that produces the desired cut-off frequency.  The position of the pole also affects the filter gain.  If, as in this application, you don't care exactly where the cut-off frequency is, you can place the pole so as make the arithmetic easy, i.e. to eliminate the need for multiplications.  By placing the pole at (0.75, 0), the only non-unity coefficient is 0.75, which is just an add, two shifts and a subtract, and the filter gain is 8, easily managed with three shifts.

In addition to multiply-accumulates, a characteristic of digital filters is the need to shift delay lines of samples.  However, in a first-order IIR filter, both the input and output delay lines are only two samples in length.  Rather than shift anything, the selected filter implementation duplicates the algorithm and exchanges the locations of the samples.  Depending on the least significant bit of the index into the circular buffer, one of the two algorithms executes, placing the new sample in one of the two places in the input delay line and placing the computed result in one of the two places in the output delay line.  The next execution will reverse the positions, making actual data movement unnecessary.

Using the implementation tricks described, the ADC conversion complete interrupt service routine, which executes the filter, uses less than 15% of the CPU with the clock at 7.3728 MHz and optimization set at -O0.

Firmware

Firmware Tool Set

The firmware for the microcontroller was written in Atmel's AVR Studio using the GCC compiler in the WinAVR package.  The ATmega64 has JTAG on-chip debugging and the firmware was loaded and debugged using an ECROS Technology AVR ICE-Cube (which behaves as if it were an Atmel JTAG ICE).

As was mentioned above, the ECROS operating system was installed.  The benefits of a multi-tasking operating system include the ability to write the software for a fairly complex function and then forget it, knowing it will continue to work while you construct the rest of the application around it.  Once the motor control function was completed, including current interruption detection, the application would just call a function to start the motor and receive a callback when the motor had completed its single revolution and returned to the home position.  The operating system looked after timing and scheduling of the CPU.  An additional benefit of ECROS is the small memory footprint and the absence of the need for task synchronization.  As with many applications, this one was well suited to a co-operative, run-to-completion task scheduler.

Resources