Encoders

[YahooArchive]

I had some experiences..
Tell us your encoder resolution and the rotational max. speed (rpm) of
"whatever" you'll attach to it..

and.. counters (which has 1 pulse and 1 up/down pins) will not work with
encoders.. whether if you had two.. And if you know a cheap 2 phase inputs
counter IC which determines the direction from phase order, let me know also..

But if pulse width of encoder channels is appropriate, you may not need counters
nor special circuitry instead of using LCP21xx with some programming...

Suha

----- Original Message -----
From: Mike Asker
To: ARMexpress@yahoogroups.com
Sent: Thursday, December 04, 2008 8:45 AM
Subject: [ARMexpress] incremental encoder


Has anybody here had any experience interfacing to an incremental encoder?
(As the shaft rotates it outputs two square waves shifted by 90deg whose
frequency
is determined by rotation speed, and the rotation direction is
determined by which of
the square wave signals is leading)

It looks like I need a continuously running up-down counter, clocked by
my encoder
square wave. It doesn't look like the LCP21xx parts support this type
of counter.
I suspect I will have to design my own counter circuit.

-mike

[YahooArchive]

Do this in software ? Setup an interrupt-on-digital-input-state-change
(I believe the ARMite can do this, not sure about ARMexpress) and
connect one of the phases to that. In that interrupt procedure, check
the logic state of the other phase which will then tell you direction.
Read time in the interrupt procedure to get the encoder frequency.

--- In ARMexpress@yahoogroups.com, Mike Asker <mike.asker@...> wrote:
>
> Has anybody here had any experience interfacing to an incremental
encoder?

[YahooArchive]

Mike,

I used an encoder of that type in an application where the encoder was part of
the user interface and used to manually tune a receiver. The main control
program ran a continuous loop about 100 times a second. The loop called the
function below every time and took appropriate action based on the function
return. Setting the LoopCounter to 0 ensured bypassing the timer that set the
loop repetition rate and thus prompt response. It ran without apparently ever
dropping counts on an ARMExpress. Enjoy, Dick Grubb

EncoderHB, LB - are Const pin definitions

LastHB, LB, LoopCounter are Global Integers

Function ReadEncoder 'returns -1,0 or 1 for each call
'read the encoder bits and detect rotation
Dim HB as Integer
Dim LB as Integer
Dim Diff as Integer
HB = IN(EncoderHB)
LB = IN(EncoderLB)
If HB = LastHB and LB = LastLB Then
Diff = 0
Else
If HB XOR LastLB = 0 Then
Diff = -1
Else
Diff = 1
EndIf
LoopCounter = 0
EndIf
LastHB = HB
LastLB = LB
RETURN diff
End Function

[YahooArchive]

Thanks for all the great suggestions!

I still have to find out the details like maximum frequency, etc.
But I think I'll might have a go at doing in software first, and see
how many cpu cycles it takes.

-mike

[YahooArchive]

You did not say if your encoder was manually operated. Obviously whether this
simple software will work depends on the 'cycle rate' and that depends on the
number of cycles per rev and the revolution rate. My encoder was a Grayhill
61C11-01-08-02 (Digikey PN# GH6102-ND), optical with 32 pulses per rev. You
could spin it by hand as fast as you liked and the software did not seem to miss
a beat. Enjoy, Dick

----- Original Message -----
From: Mike Asker
To: ARMexpress@yahoogroups.com
Sent: Thursday, December 04, 2008 8:39 PM
Subject: Re: [ARMexpress] incremental encoder


Thanks for all the great suggestions!

I still have to find out the details like maximum frequency, etc.
But I think I'll might have a go at doing in software first, and see
how many cpu cycles it takes.

-mike

[YahooArchive]

I just powered it up. It's driven by a 0.5hp motor running at ~1800rpm.
It outputs a 5v square wave at 30kHz at max speed,
Which gives about 1000 pulses per revolution.

At this frequency I will need to an external counter to keep

-mike

[YahooArchive]

O.k. then.. So you have a 1800 rpm motor and a 1000 CPR encoder..
next question should be; what is your priority?
1. position reading/control ?
2. speed reading/control ?
3. Torque reading/control ?

and let me remind you; a 1000 CPR (cycle per rev.) encoder with two phases (A-B)
plus 90 degrees phase shift between them; counts to a quadrature output of 4000
positions per rev. The second phase not only gives direction, it also multiplies
the positioning resolution with 4.

So if your application is position control and you want max. precision at hand,
your cpu should be capable of making 120.000 readings from its Input port.

But it is still possible with LCP21xx, you are having 10 million Basic
instructions per second with armmite, enough to read multiple encoders, make
position calculations and output pulse/direction signals for a multi-axis robot.
Then the bottleneck should be port speed, but it is also 1Mhz; which gives you
opportunity of 1 million readings per second seems still suitable for catching
120Kpulses (combined). If you are using interrupts, It is much more easier to
write code for other things, but other way it is still possible (I did similar
in assembler with a 1Mhz cpu Commodore64, 20 years ago)

I think real trouble of doing this is preserving signal quality of encoders
among those motors, power supplies etc. If you go that way let me know so we can
exchange experience about cabling, shielding, noise problems.

If you are looking for speed reading/control only, this resolution is much ahead
of any need, I suggest you to buy a 100 cpr encoder at most and use one channel
only.. Then it will be much easier to write code and you still should not worry
about missing pulses.

Suha

[YahooArchive]

Hi,

Using twisted pairs works very fine if you have the inverse signals, a
shielded cable like Cat5 or Cat6 is suitable if the cable is -not- moving,
(moving with axis). Otherwise you should consider using cables designed for
robotic cable ducts because movement kills the ordinary cables in a short
time...

A couple of naive suggestions;
- make sure the inverses take the pairs, ex.; green-greenwhite to take A
and A inverse.. (I confused colors once and it gave a lot of headaches)
- if you are grounding the shield, make sure you do it only on one side,
(preferably controller side) and isolate the other end. This is for avoiding
(accidental or not) ground loops..
- If you have a long distance to go with cable (like 10m/30 feets) in a noisy
environment, you may consider using cable drivers (U.S.Digital again)


Suha