Searching \ for 'Counting encoder pulses' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/sensors.htm?key=encoder
Search entire site for: 'Counting encoder pulses'.

Truncated match.
PICList Thread
'Counting encoder pulses'
1998\01\27@064042 by Philip Cowley

flavicon
face
>Philip Cowley wrote:
>
>> I need to count the pulses coming from a pair
>> of quadrature incremental encoders.
>
>Are these optical encoders, or mechanical?

I have a matched pair of optical encoder disks which I am having mounten on
to shafts. The disks have 1458 lines, which produces 5832 quadrature
transitions.

>The latter have _awful_ signals.

I know... but reasonable optical encoders are not actually that difficult to
build.

>What's the app?

Ahhh there's the rub!
   I am building a computer control system for a large astronomical optical
telescope. The telescope weighs about a ton (1000kg) and is driven by a pair
of synchro motors. These are currently controlled by some analogue
electronics from a small joystick.
   The first step is to provide the computer with position information from
the telescope.
   The telescope has two axis of rotation, R.A. and Dec. The encoder on
R.A. axis is attached to a large ring on the telescope mount, by a toothed
belt, giving a ratio of 300:1.... thus the encoder produces 1749600
pulses/revolution... or 4860 pulse/deg.
   The encoder on Dec. axis is attached to a smaller ring on the telescope
mount, by a toothed belt, giving a ratio of 100:1.... thus the encoder
produces 583200 pulses/revolution... or 1620 pulse/deg.
   The computer will eventually drive the analogue motor drivers thus
closing the control loop.

   The accuracy of the encoders may seem a bit OTT, but I really do need
it!

Thanks for any help...

Phil

1998\01\27@085232 by mike

flavicon
picon face
In message  <01bd2b18$07724260$spam_OUT083d11acTakeThisOuTspamheartofgold.satellites.twin.dev>> .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU writes:
{Quote hidden}

[snips]

Phil,

I would suggest that you don't do the quadrature decoding in the
PIC, but rather use on of the decoder chips from either Texas or
Hewlett Packard.

I have used HPs HCTL2016 successfully in a PIC project. It has 16
pins, maintains 16 bit pulse count which is read using an 8 bit
bus. In my project, I read the 2016 every 1ms adding the difference
of the count into a 32 bit accumulator which is then multiplied by
a 16 bit number for calibration before sending the most significant
32 bits serially to a DSP chip.

Regards,

Mike Watson

1998\01\27@092741 by Philip Cowley

flavicon
face
>Phil,
>
>I would suggest that you don't do the quadrature decoding in the
>PIC, but rather use on of the decoder chips from either Texas or
>Hewlett Packard.


I have a little circuit that transforms the quadrature signals into up and
down pulses (just a pair of NAND gate if memory serves).  Then I was going
to drive the PIC interrupts with these up down (and reset) signals.

Phil

1998\01\27@140111 by Bob Blick

face
flavicon
face
>     The telescope has two axis of rotation, R.A. and Dec. The encoder on
> R.A. axis is attached to a large ring on the telescope mount, by a toothed
> belt, giving a ratio of 300:1.... thus the encoder produces 1749600
> pulses/revolution... or 4860 pulse/deg.
>     The encoder on Dec. axis is attached to a smaller ring on the telescope
> mount, by a toothed belt, giving a ratio of 100:1.... thus the encoder
> produces 583200 pulses/revolution... or 1620 pulse/deg.

What is the maximum rate that you can expect? You can just poll the
encoders during a timer-based interrupt quite frequently, 50k per second
or more, and not have to deal with any messy external parts. If the data
rate is low enough... Testing for overspeed is easy to do within the loop,
so if you are not sure, just write some test code, hook a PIC to the
encoders, and run the scope as is to see if you overrun(both phases of an
encoder change since last check), then turn on an LED or something...
That'd at least give you an idea if it's going to work. If you have 6000
pulses per degree, you could swing that telescope 8 degrees per second
without an overspeed error at 50k interrupts per second.

-bob

1998\01\27@143801 by Steve Baldwin

flavicon
face
Seems like automated telescopes are all the rage. Our one is small compared
to yours (11" SCT), but is fully automated and (will) live on its own on a
hill measuring variable stars with a PMT.
We used microstepped steppers plus gearing and have similar OTT numbers for
pulses/degree.

If you assume 2 minutes for a 180 degree slew in RA (which would seem
reasonable for flinging a ton of steel and glass around with arc-second
resolution)  that works out to 130 microseconds between pulses, which I
would have thought would be easy for a PIC to handle. It depends on what
else it was doing. If you have to do both encoders and convert between
coordinate systems at the same time, you might be pushing it.

Steve.


>     I am building a computer control system for a large astronomical
optical
> telescope. The telescope weighs about a ton (1000kg) and is driven by a
pair
> of synchro motors. These are currently controlled by some analogue
> electronics from a small joystick.
>     The first step is to provide the computer with position information
from
> the telescope.
>     The telescope has two axis of rotation, R.A. and Dec. The encoder on
> R.A. axis is attached to a large ring on the telescope mount, by a
toothed
> belt, giving a ratio of 300:1.... thus the encoder produces 1749600
> pulses/revolution... or 4860 pulse/deg.
>     The encoder on Dec. axis is attached to a smaller ring on the
telescope
> mount, by a toothed belt, giving a ratio of 100:1.... thus the encoder
> produces 583200 pulses/revolution... or 1620 pulse/deg.
>
>     The accuracy of the encoders may seem a bit OTT, but I really do need
> it!

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: stevebspamKILLspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1998\01\27@150439 by Joe Little

flavicon
face
    I had a little funny that took me an unpleasant while to find.

    If there's a little vibration or electrical noise, the count may creep a
    little without the encoder moving a full click.  I had about 5 inches of
    cable, and a 512 count encoder.  Seemed simple enough, so I just ran the
    two channels into the pins on the processor with 2.2k ohm pullups.

    After awhile, I found that I could move the encoder until I could see
    channel A change state, and rock it back and forth (without channel B
    moving).  This shouldn't have incremented the position counter, but it was.

    I fixed it with a .01uF cap on each channel input at the encoder connector,
    and a lot smarter algorithem to move the position counters.  (The code is
    in a PLD not a PIC... but the story would have been the same)

    I had the time and budget to get away without the HP interface chip.  If I
    had better things to do, or production quantities were low enough I would
    have definatly dropped in a decoder chip.

    Joe

    --------------



    >Phil,
    >
    >I would suggest that you don't do the quadrature decoding in the >PIC, but
    rather use on of the decoder chips from either Texas or >Hewlett Packard.


    I have a little circuit that transforms the quadrature signals into up and
    down pulses (just a pair of NAND gate if memory serves).  Then I was going
    to drive the PIC interrupts with these up down (and reset) signals.

    Phil
    --------

1998\01\27@160147 by Montaigne, Mike

flavicon
face
> After awhile, I found that I could move the encoder until I could see
> channel A change state, and rock it back and forth (without channel B
> moving).  This shouldn't have incremented the position counter, but it
> was.
>
(IMHO)  This should increment the position counter but when you moved it
back it should decrement it again.  We see this all the time.  Your
logic should take care of this rather than depending on a r/c network to
get rid of it.
have a nice day, Mike Montaigne

{Quote hidden}

1998\01\27@174854 by Mauro, Chuck

flavicon
face
A few questions for you Phil,

1) Is your optical encoder detented? (You can feel it click - not a
smooth rotation)
2) Are the output from the photodetectors conditioned in any way (i.e.
digital), or are they "raw"?

The reason I ask, is that depending on the above, entirely different
processing is needed.  In the mouse biz, the encoders are not detented,
and as a result, the mouse can be "parked" at the transition point of
the shaft encoders (the photodetectors (darlingtons) drive the uC pins
directly).  So, jittery or "creeping" cursor motion became a problem in
early designs.  The way around this was to throw away a valid transition
on direction reversal - this is essentially firmware hysteresis .  But,
in your case, I suspect that you never want to lose a count on direction
change in order to isolate noise...

John Payson's earlier response in this thread talked about the way to
properly deal with mechanical style encoders: "The key is to interpret
the encoder as progressing through the states "1X X1 0X X0" rather than
the more conventional "11 01 00 10".  Since at least one of the two
contacts should be stable at any given time, the encoder will always be
stable in at least one of the four positions mentioned."

He is entirely correct.  You might have assumed that this doesn't apply
to your case because your encoders are optical.  In fact, John's
analysis DOES apply to an optical if the encoder is detented.  The basic
issue here is the fact that the encoder is an opto-mechanical system.
The key word being mechanical.  With tolerance stack-ups, including die
placement in the IR LEDs, Phototransistors or PIN photodiodes,
interrupter placement, injection molding tolerances, etc., even a
detented positioning system can create a band of uncertainty (+/-
angular displacement) so large around the "rest" position of the encoder
(stopped in a detent), that if the thing's not designed well, the slot
encoder can rest too near the electrical transition region of a
detector.  This can cause the unwanted "noise" you have indicated.

This was a subject I studied in detail while designing mice, and other
encoding systems using detented quadrature encoders, both purely
mechanical and opto-mechanical.  The opto variety are superior, for lots
of reasons discussed by myself and others, but it's that darn detent
that can in reality be the true Achilles heel, if you are indeed using
this kind of a system.

I hope this helps shed some light.


Chuck Mauro

> {Original Message removed}

1998\01\27@183214 by John Payson

picon face
> The reason I ask, is that depending on the above, entirely different
> processing is needed.  In the mouse biz, the encoders are not detented,
> and as a result, the mouse can be "parked" at the transition point of
> the shaft encoders (the photodetectors (darlingtons) drive the uC pins
> directly).  So, jittery or "creeping" cursor motion became a problem in
> early designs.  The way around this was to throw away a valid transition
> on direction reversal - this is essentially firmware hysteresis .  But,
> in your case, I suspect that you never want to lose a count on direction
> change in order to isolate noise...

While it would seem nice not to have the encoder be "off" by a count on dir-
ectional changes the effect is non-cumulative and in fact may in some cases
be a GOOD thing depending upon how the encoder is located relative to the
object in question and its driving force.  If your encoder is on a motor which
is moving the telescope, the backlash of the encoder's hysteresis will work
to counteract mechanical backlash in the system.  This is the only way of
mounting which can be made reliable around direction changes, and even here
you may still have to take measurements of mechanical backlash (which will
probably be greater than one encoder pulse) and compensate.  Alternatively,
you could always approach target positions from the same direction, analagous
to the way many musical instruments are tuned (e.g. on a violin, you always
tune by raising a string to the correct pitch; if the pitch is too high, you
loosen the string below the correct pitch and then tighten it to raise the
pitch).  In this case, the one-count offset on direction changes will be a
non-issue.

1998\01\27@183647 by Mauro, Chuck

flavicon
face
Good point, John, thanks for expanding on the issue...

- Chuck

{Quote hidden}

1998\01\27@233512 by mike

flavicon
picon face
In message  <01bd2b2e$cb6a6740$KILLspam083d11acKILLspamspamheartofgold.satellites.twin.dev>> RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU writes:
> >Phil,
> >
> >I would suggest that you don't do the quadrature decoding in the
> >PIC, but rather use on of the decoder chips from either Texas or
> >Hewlett Packard.
>
>
> I have a little circuit that transforms the quadrature signals into up and
> down pulses (just a pair of NAND gate if memory serves).  Then I was going
> to drive the PIC interrupts with these up down (and reset) signals.
>
> Phil
>
Phil,

I have done this too, but the noise and jitter immunity isn't up to much.
If you are interested in the sort of resolution you say you are interested
in, and if you are not selling thousands of these things, the benefits
of using a dedicated chip cannot be understated.

The HCTL2016 is available for about =A315 from Farnell. Check out the
data sheet - then you will see the issues that are involved and how
this chip overcomes them.

Best regards,

Mike

--
Denison Mayes Group

1998\01\28@054123 by Philip Cowley

flavicon
face
-----Original Message-----
From: Steve Baldwin <spamBeGonestevebspamBeGonespamKCBBS.GEN.NZ>
To: TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Date: 27 January 1998 19:38
Subject: Re: Counting encoder pulses


>Seems like automated telescopes are all the rage. Our one is small compared
>to yours (11" SCT), but is fully automated and (will) live on its own on a
>hill measuring variable stars with a PMT.
>We used microstepped steppers plus gearing and have similar OTT numbers for
>pulses/degree.


Are you counting the pulses to the stepper motors or have you got separate
encoders?

We've had our 30inch running for 10 years with an analogue control system,
but we now want to improve the drive and add extra safety measures like
automatic dome positioning.

>It depends on what
>else it was doing. If you have to do both encoders and convert between
>coordinate systems at the same time, you might be pushing it.

The PIC will only count the two encoders pulses and output the counts to a
PC... The PC does all the hard work of coordinate mapping and user
interface!

Phil

1998\01\28@054954 by Philip Cowley

flavicon
face
>What is the maximum rate that you can expect?

It just seems that a for simplicity the following is best...

Encoder quadrature signals are converted to up/down by a single 74 series
chip. (a double NAND gate I think!)
These up/down pulses are fed into the PIC interrupt pins.
Code is written to handle the interrupts
Code is written to output the current counts via an RS232.

As a WindowsNT programmer by trade I am used to writing event driven code,
so that should not be a problem.

The maximum slew speed of the 'scope is about 5-10deg/s ~= 30K - 60K
pulse/sec.

1998\01\28@055203 by Philip Cowley

flavicon
face
>A few questions for you Phil,
>
>1) Is your optical encoder detented? (You can feel it click - not a
>smooth rotation)


The movement will be smooth. No clicks.

>2) Are the output from the photodetectors conditioned in any way (i.e.
>digital), or are they "raw"?

The signals are conditioned by a schmidt trigger to give it a bit of
hysteresis, before it is passed through the NAND gates to give up/down
instead of quadrature signals.

Phil

1998\01\28@055616 by Philip Cowley

flavicon
face
>While it would seem nice not to have the encoder be "off" by a count on
dir-
>ectional changes the effect is non-cumulative and in fact may in some cases
>be a GOOD thing depending upon how the encoder is located relative to the
>object in question and its driving force.  If your encoder is on a motor
which
>is moving the telescope, the backlash of the encoder's hysteresis will work
>to counteract mechanical backlash in the system.

I thought of this and decided to mount my encoders separately from the
motors on their own lightweight backlashless (or as close as possible)
toothed belts.

I am over sampling by a factor of 10 anyway so as long as the errors are not
cumulative, I'm not too worried!

Phil

1998\01\28@203646 by Steve Baldwin

flavicon
face
> >We used microstepped steppers plus gearing and have similar OTT numbers
for
> >pulses/degree.
> Are you counting the pulses to the stepper motors or have you got
separate
> encoders?

I'm counting pulses. The steppers are micro-stepped 128x and a full speed
slew is just over 1MHz input pulse rate. I was expecting to have problems
with mechanical slippage and/or possibly stepper/translator errors, but it
seems to work well. I'm using simple opto interrupters for reference points
and getting repeatability of around an arc-second on a limit to limit slew.

All of this is being done by an 8 bit micro, including environmental
monitoring, opening/closing the observatory, measurement scheduling,
positioning, filter selection, photon counting from the PMT, simple error
checking for clouds etc and then emailing the results to the appropriate
people after a night observing. Excluding the stepper translators and the
modem, the whole controller cost <$1000 for 5 units.

Now they want to use area CCDs (which we technical types wanted in the
first place), so the whole exercise was a bit of a waste of time. The CCD
needs a hard disk to save piles of data and has a huge field of view
(compared to a PMT) so a commercial controller, CCD and PC probably would
have done the job.
Aarghh ! Bloody astronomers. :-)

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: stevebEraseMEspam.....kcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1998\01\29@061046 by Philip Cowley

flavicon
face
<BIG SNIP>

>Now they want to use area CCDs (which we technical types wanted in the
>first place), so the whole exercise was a bit of a waste of time. The CCD
>needs a hard disk to save piles of data and has a huge field of view
>(compared to a PMT) so a commercial controller, CCD and PC probably would
>have done the job.
>Aarghh ! Bloody astronomers. :-)

I suggest using two PCs... the one you have (if it aint broke, don't fix
it!) and another to handle the CCD... a PC will have its hands full with the
CCD alone.

As I have posted elswhere... I think I'll use a encoder controller/counter
chip (HCTL2016) directly interfaced to my PC... that way I don't have to
learn how to use PICs.... I want to keep the system a s simple as possible.
I'm a software engineer by trade, but only a hobbyist electronics tech.

Phil

1998\01\29@165901 by Steve Baldwin

flavicon
face
> I suggest using two PCs... the one you have (if it aint broke, don't fix
> it!) and another to handle the CCD... a PC will have its hands full with
the
> CCD alone.

That was the point. Up until now, it didn't need any PCs. Low power and low
cost were the objective so the observatory could be solar/wind powered. The
whole thing (obs, scope, measurement, email) is done by a single 8 bit
micro and it's still got plenty of processing up its sleeve. Adding CCD
functions still wouldn't overload it. It's simply the huge gob of data and
where to put it.
Measuring star X with a PMT needs 64 bytes per item (with sky, comparison,
ref, etc). The same thing with a CCD needs 500k. Add to that the power
consumption of the Peltier device and both objectives go out the window.
But you do get pretty pictures. :-)

Steve.


'Counting encoder pulses'
1998\02\01@074838 by paulb
flavicon
face
Philip Cowley wrote:

> As I have posted elswhere... I think I'll use a encoder controller/
> counter chip (HCTL2016) directly interfaced to my PC... that way I
> don't have to learn how to use PICs.... I want to keep the system as
> simple as possible.  I'm a software engineer by trade, but only a
> hobbyist electronics tech.

 Sad.  Using the PICs, and particularly the 16F84, plus the HCTL2016
you could integrate the position detection and (later if necessary, as
the 16F84 is generously and in-circuit re-programmable) motor control
functions into the mount, with a very minimal RS-232 or indeed RS-485
link to your control computer, the latter using a basic serial port
whcih I am sure you already have too.  Or consider optical (how very
*appropriate*)!

 The concept is - use local intelligence and minimise cabling wherever
possible.  If it isn't immediately cheaper, it's going to be more
reliable, (because it's .. ) much simpler to use, simpler to maintain
(both software and cables) and likely more accurate.  Consider, for
example, the ability to bring in another computer (the first one fails
maybe) and plug it straight in.

 Some of us (maybe me, but maybe more likely the chap within biking
distance) would probably be quite happy to do the PIC stuff for you!
The boards are available ready-designed ( http://www.dontronics.com/ )
for you.

 My thoughts.  Cheers,
       Paul B.

1998\02\02@052858 by Philip Cowley

flavicon
face
<SNIP>

>  The concept is - use local intelligence and minimise cabling wherever
>possible.  If it isn't immediately cheaper, it's going to be more
>reliable, (because it's .. ) much simpler to use, simpler to maintain
>(both software and cables) and likely more accurate.  Consider, for
>example, the ability to bring in another computer (the first one fails
>maybe) and plug it straight in.

I cannot drive the motors locally, but have to rely on the electronics
currently doing the job, which is sited at the control station in the dome
(where I am putting the PC!). The motors are large synchro and require
dedicated driver hardware.

>  Some of us (maybe me, but maybe more likely the chap within biking
>distance) would probably be quite happy to do the PIC stuff for you!
>The boards are available ready-designed ( http://www.dontronics.com/ )
>for you.

Many thanks for your offer, but I have devised a very simple board to read
the encoders... As a software engineer I can centralise the intelligence in
the PC and only have one developement environment to worry about in future
years!

Much thanks for all your help, everyone.

Phil

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...