DPRG mailing list archives: [DPRG] Handy Board and Encoders

Wed Sep 5 09:54:24 CDT 2001

Several have mentioned the case of the motor stopping and the encoder being
on a line. Thus causing jitter.  I have not observed this in practice when
using a Schmitt triggered detector (like the Hamamatsu has - or adding my
own on when using other detectors).  Is this a real problem when it is
properly accounted for?  Generally, I wouldn't think I would be sampling if
the motor is stopped.

I *have* seen it occur when I didn't use a Schmitt.

Dan

-----Original Message-----
>From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
Of Kipton Moravec
Sent: Wednesday, September 05, 2001 9:09 AM
To: Dan Miner
Cc: DPRG List
Subject: Re: [DPRG] Handy Board and Encoders

The other option is to use a CPLD and let the hardware keep track of the
counts.  The processor just sees a data register, 8- 16- or 24-bits for each
channel.

If it is only 8 bits you have to sample the data 1 time every 128 clocks
encoder steps (or faster).  That means at least every 2.56 milliseconds
which is better.  If it is 16 bits, then it is every .65 seconds.  Since you
should be closing the loop in your controller faster than that which should
be easier, but I think either 8- or 16- bits will work.

We still get back to the jitter problem.  David Anderson says he has not
seen it, but I do not see how it can not be there, unless the motor has
detents. (Which I doubt).  The concern is what happens when the motor stops
and the encoder interrupt is on the line.  It is possible that it can start
to wiggle enough that it starts sending interrupts because it is switching
>from black to white or on and off. Even though the motor is not turning.
Since the other sensor is still in the middle of its color, the counter will
count either up or down.

To avoid this, you need a state machine.  That can only be done in hardware.
The microcontroller is not fast enough.
The state machine is what the LS7803 and LS7804 are.  Or you can roll your
own with a CPLD.

Kip

----- Original Message -----
>From: "Dan Miner" <miner at centtech.com>
To: <dprglist at dprg.org>
Sent: Wednesday, September 05, 2001 1:22 AM
Subject: RE: [DPRG] Handy Board and Encoders

> A slight math typo:
>
> > ... 50k per second, about 1 pulse every 2 microseconds...
>
> That should be 1 pulse every 20 microseconds.
>
> Still way to fast for Interactive C.  You could keep
> up with it using VERY finely tuned assembler but you
> could only do 1 channel and you'd have no time for
> anything else.
>
> Recommendation is to divide down the frequency of the
> signal using a counter chip (as David suggested) or
> switch processors to something like a 68332 (Mini Robo
> Mind) that has a TPU hardware that will keep track of
> the encoders for you.
>
> - Dan Miner
>
> > -----Original Message-----
> > From: David Peterson [mailto:robologist at yahoo.com]
> >
> > Hey Ed,
> >  Think those motors you've got run about 1000 rpm out the
> > gear shaft, which means the encoder end is twirling at about
> > 6000 rpm. Times 500 is 3 million per minute or 50k per
> > second, about 1 pulse every 2 microseconds possible (in no
> > load). A Basic Stamp 2 can pick up a 2 us pulse, but
> > probably not consecutively, so I'm guessing that a
> > Handyboard could as well. Storing all those pulses might be
> > the real problem. Trying to do 4x mode might be a problem
> > too, and the HCTL chip Tom mentioned could help, but think
> > it's $18+ (x2) unless it can be sampled. Oh, those encoders
> > should be HEDS 9100. Other quad encoder chips include the
> > LS7083 and 84 ($3 x 2) at
> > http://www.usdigital.com/products/ls7083-84/ which then
> > interface with a counter logic chip like a 74xx193. Also
> > there's the LS7166 ($12 x 2) and 266 ($16 x 1) too, more
> > direct to an MCU. I could be wrong about that price too.
> > David P
> >
> > ----- Original Message -----
> > From: "Ed Okerson" <eokerson at fw.telenic.net>
> >
> > > I am working on a robot that has Pittman motors with built
> > in encoders.  The
> > > encoders appear to be 500 slots per revolution of the
> > motor shaft, and the
> > > gearbox is 5.9:1.  Is it possible for the handyboard to
> > keep up with that
> > > pace of pulses?  Or do I need to implement some sort of
> > divider to reduce
> > > the pulse count?  So far just playing with Interactive C
> > and it's encoder
> > > routines, it seems to loose many pulses if the motor speed
> > is anywhere above
> > > the speed of a crippled snail.
> > >
> > > Ed Okerson
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist

_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org
http://nimon.ncc.com/mailman/listinfo/dprglist