Searching \ for '[EE] Rotary Encoder Implementation' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/sensors.htm?key=encoder
Search entire site for: 'Rotary Encoder Implementation'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Rotary Encoder Implementation'
2011\10\11@113755 by Kerry Wentworth

flavicon
face
I would like to see the code.  I don't understand from your description.

Kerry


spam_OUTjimTakeThisOuTspamjpes.com wrote:
{Quote hidden}

>

2011\10\11@130817 by Andre Abelian

picon face
Good idea Jim,

I like to see the code too. I am hopping it's not assembly 

thanks

Andre


________________________________
From: Kerry Wentworth <.....kwentworthKILLspamspam@spam@skunkworksnh.com>
To: Microcontroller discussion list - Public. <piclistspamKILLspammit.edu>
Sent: Tuesday, October 11, 2011 8:36 AM
Subject: Re: [EE] Rotary Encoder Implementation

I would like to see the code.  I don't understand from your description.

Kerry


.....jimKILLspamspam.....jpes.com wrote:
{Quote hidden}

2011\10\11@131633 by jim

flavicon
face


Andre,

Yes, it is in assembly.  I program almost exclusively in assembly.
But I will post it later today.

Regards,

Jim

> ---{Original Message removed}

2011\10\11@151401 by Peter Johansson

picon face
On Tue, Oct 11, 2011 at 1:08 PM, Andre Abelian <EraseMEabelian.andrespam_OUTspamTakeThisOuTyahoo.com> wrote:

> I like to see the code too. I am hopping it's not assembly

Take a look at the piclist techref link posted earlier in this thread.
The algorithm is clearly described, and it is easy to follow the code
with only the most basic knowledge of ASM.

I had a hard disk fail on me last week, and have since disassembled it
and figured out how to read the pulses generated by the drive motor
when the platter is spun by hand.  I haven't gotten around to writing
the driver code, but the above algorithm will sure help with that.
FWIW, I'm using C to target an MSP430...

-p

2011\10\11@184734 by Christopher Head

picon face

{Quote hidden}

I assume we're talking about a quadrature-output rotational encoder
here; ignore if not.

This will probably work fine when spinning the knob, but it could fail
if the input is mostly still but jittering slightly. The outputs of a
rotary encoder are in quadrature, so across a full output cycle, A will
rise, then B will rise, then A will fall, then B will fall. Imagine if
the knob is sitting right by the position where A rises, and is
jittering slightly. You'll see the A output oscillating while B remains
stable. Your example algorithm will count rapidly. A full
quadrature-decode will simply add and subtract one repeatedly in this
situation, accurately reflecting the physical reality. Also, doing
proper quadrature decoding eliminates the need to do debouncing
altogether, since any possible jitter occurs on only one output at a
time and hence can only change the counter value by ±1. And it gives
you 4× the resolution.

Chris

2011\10\11@231532 by jim

flavicon
face

No it won't "count rapidly".  Because I wait for the outputs to go to
the normal resting state before I exit the routine where it adds to the
count variable.  I have been playing with the encoder to get it to mess
up, but I haven't been able to so far.  It works for me as it is. YMMV.
I don't claim it to be bulletproof.  All I claim is that I wrote it using
Information gleaned from observation of the encoder at work using a DMM,
And from others code posted on the internet.

Regards,

Jim

{Original Message removed}

2011\10\11@234719 by Kerry Wentworth

flavicon
face

Correct me if I'm wrong, but this encoder is mechanical, not optical,
and it has detents, and moving from 1 detent to the next equals 360
degrees of electrical travel.  I have tried to use my normal optical
encoder software with such encoders with poor results.

Using 4X or even 2X algorithms would have no advantage with such
encoders.   Also, they will never sit on the edge of  A or B changing
with small vibrations. They will sit in a detent halfway between A
change and B change.

Kerry



jim wrote:
{Quote hidden}

> {Original Message removed}

2011\10\12@095116 by jim

flavicon
face


ok.  but how does that equate to counting rapidly?  just curious.


Regards,

Jim

{Quote hidden}

> > {Original Message removed}

2011\10\12@101910 by Kerry Wentworth

flavicon
face

Little enough to do with fast counting, I suppose, although the usual
purpose of such encoders doesn't really require a rapid response.  I'm
just trying to make sure we are all talking about the same thing.  Both
encoders types have quadrature outputs, but code that works great for
one might not be that great for the other.  I think your code is great
for mechanical type encoders like I described, and when I get a chance
to get back to my mechanical encoders I'm going to try it.

Kerry


RemoveMEjimTakeThisOuTspamjpes.com wrote:
{Quote hidden}

>>> {Original Message removed}

2011\10\12@124125 by Andre Abelian

picon face
Kerry,

mechanical or optical encoders output exact same data regardless of having detent or no detent.

Andre 




________________________________
From: "RemoveMEjimspamTakeThisOuTjpes.com" <jimEraseMEspam.....jpes.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistspammit.edu>
Sent: Wednesday, October 12, 2011 6:51 AM
Subject: RE: [EE] Rotary Encoder Implementation


ok.  but how does that equate to counting rapidly?  just curious.


Regards,

Jim

{Quote hidden}

> > {Original Message removed}

2011\10\12@171320 by Barry Gershenfeld

picon face
I've been known to remove the detent, to allow the knob to turn more
easily...

2011\10\13@024534 by Christopher Head

picon face

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Ah that explains it; I wasn't aware we were talking about encoders with
detents. I've only ever touched optical encoders, where a quarter of a
quadrature cycle equals a quarter of a degree (in my case) of shaft
rotation. In this situation, "wait[ing] for the outputs to go to the
normal resting state" won't do anything, because if (00) is the normal
resting state, then you can still go (00)/(01)/(00) without applying a
net rotation to the shaft, and yet you'd count that as +1 using an
algorithm that doesn't do full quadrature decoding.

Sorry for the misunderstanding.

Chris

On Tue, 11 Oct 2011 23:45:39 -0400
Kerry Wentworth <RemoveMEkwentworthTakeThisOuTspamspamskunkworksnh.com> wrote:

{Quote hidden}

> > {Original Message removed}

2011\10\13@025740 by Christopher Head

picon face

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

The difference is that an encoder without detent can rock back and
forth across a single edge, producing a sequence of output like "00",
"01", "00", "01", "00", "01".

A full quadrature decode will read this as +1, -1, +1, -1, etc.

A simple rising-edge detector will just say "rising edge detected, I
see 01, +1", "falling edge (no detection)", "rising edge detected, I
see 01, +1", "falling edge (no detection)", etc., yielding +1, +1, +1,
etc.

The presence of a detent would make it exceedingly difficult to
position the encoder just so for this to happen.

Maybe I'm misunderstanding the original code, but I took it to be
similar to a circuit I saw once that used a bidirectional counter chip
to read a quadrature optical encoder by attaching one of the encoder
lines to the counter's clock input and the other to its direction
input. Assuming A is the direction and B is the clock, the pattern I
describe above issues a lot of clock cycles with the direction line
never changing, and thus quite obviously counts a long way in one
direction.

Chris

On Wed, 12 Oct 2011 09:41:23 -0700 (PDT)
Andre Abelian <EraseMEabelian.andrespamspamspamBeGoneyahoo.com> wrote:

> Kerry,
>
> mechanical or optical encoders output exact same data regardless of
> having detent or no detent.
>
> Andre 
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEAREDAAYFAk6Wi98ACgkQXUF6hOTGP7dHPgCgmMNp8Zx2q5dzP56ZJC+1UfDP
OdcAn3xpTjTJ/xaBSm/phb2EeYZ8vsHW
=5aT5
-----END PGP SIGNATURE-----

2011\10\13@075327 by slippyr4

picon face
slightly hijacking this thread a little (and I apologise) but can some
bright mind confirm:-

I currently have a circuit which counts teeth on a gear (with a hall effect
switch).  If I were to add another sensor on the same gear, but half a tooth
apart, would the output from the two sensors then be grey code? and thus all
the above apply

2011\10\13@093434 by alan.b.pearce

face picon face
> slightly hijacking this thread a little (and I apologise) but can some
> bright mind confirm:-
>
> I currently have a circuit which counts teeth on a gear (with a hall effect
> switch).  If I were to add another sensor on the same gear, but half a tooth
> apart, would the output from the two sensors then be grey code? and thus all
> the above apply?

Not really, because the encoder relies on the wave shape being essentially square, with the pulse high being the same length as the pulse low at a given speed.

With two gears placed in the manner you propose I don't think you will get the two pulses to reliably overlap properly, especially at low speed, as the output from the sensor relies on the speed of the tooth past it for the pulse amplitude. At some suitably high speed you may be able to get the electronics to Schmitt trigger on the waveform to detect direction in a reliable manner, but as the speed drops and the sensor output amplitude drops the triggering point changes on the waveform and any overlap in the pulses will become non-overlapping at some speed.

Depending on just what you are attempting to do this may not matter. If you are just attempting to determine direction of rotation you may be able to do relative timing between pulse peaks (i.e. the time from A true to B true is less than one half B true to A true, hence going anti-clockwise).
-- Scanned by iCritical.

2011\10\13@094732 by Kerry Wentworth

flavicon
face
slippyr4 wrote:
> slightly hijacking this thread a little (and I apologise) but can some
> bright mind confirm:-
>
> I currently have a circuit which counts teeth on a gear (with a hall effect
> switch).  If I were to add another sensor on the same gear, but half a tooth
> apart, would the output from the two sensors then be grey code? and thus all
> the above apply?
>   Yes.  Actually, N+1/2 gear apart, so they don't need to be close to each other.  And it is best if the outputs are 50% duty cycle.  What you want, ideally, is the rising edge of A to fall exactly halfway between the rising and falling edges of B, and vice versa.  If the output duty cycle is far from 50%, adjust so that the edge of A occurs in the middle of the narrower pulse of B, and vice versa.

Ideal:
A__|    |__|    |__
B_|    |__|    |__|

Next best:
A______|    |______|    |____
B_____|    |______|    |_____

And use 'traditional' 4X optical encoder algorithm.

Kerry

2011\10\13@095515 by Kerry Wentworth

flavicon
face
Kerry Wentworth wrote:
{Quote hidden}

A__|  |__|  |__
B_|  |__|  |__|

Next best:
A______| |______| |____
B_____| |______| |_____



Kerry

2011\10\13@100612 by jim

flavicon
face

In addition to this, if this is an automotive type gear, (actually
called a reluctor), they typically have  a tooth missing which gives a reference signal to the controlled
circuit.  This type of missing tooth setup
is used on Crankshaft sensors to determine when the crank has gone
through 360 degrees of travel for use in
ignition timing.  Same thing with a Camshaft sensor.  And even some ABS
systems have a missing tooth,
although not too many use this method.  
Anyway, if you were to process the output signal of the hall effect
sensors, you might be able to get it to
work.  But alignment of the sensors will be critical.  It might be
easier to retrofit a quadrature encoder  to the end of the shaft and use that.

Regards,

Jim

> ---{Original Message removed}

2011\10\13@100637 by Kerry Wentworth

flavicon
face
slippyr4 wrote:
> slightly hijacking this thread a little (and I apologise) but can some
> bright mind confirm:-
>
> I currently have a circuit which counts teeth on a gear (with a hall effect
> switch).  If I were to add another sensor on the same gear, but half a tooth
> apart, would the output from the two sensors then be grey code? and thus all
> the above apply?
>   Are you using one of these?

http://www.allegromicro.com/en/Products/Categories/Sensors/ats.asp

Kerry

2011\10\13@105829 by Dave Tweed

face
flavicon
face
Kerry Wentworth wrote:
> slippyr4 wrote:
> > I currently have a circuit which counts teeth on a gear (with a hall effect
> > switch).  If I were to add another sensor on the same gear, but half a tooth
> > apart, would the output from the two sensors then be grey code? and thus all
> > the above apply?
>
> Yes.  Actually, N+1/2 gear apart, so they don't need to be close to each
> other.

Actually, the sensors need to be an odd multiple of 1/4 tooth apart; e.g.,
2.75 teeth or 4.25 teeth. Half a tooth would give you signals 180 degrees
out of phase, not nearly as useful.

-- Dave Twee

2011\10\13@110528 by Kerry Wentworth

flavicon
face
Dave Tweed wrote:
> Kerry Wentworth wrote:
>  
>> slippyr4 wrote:
>>    
>>> I currently have a circuit which counts teeth on a gear (with a hall effect
>>> switch).  If I were to add another sensor on the same gear, but half a tooth
>>> apart, would the output from the two sensors then be grey code? and thus all
>>> the above apply?
>>>      
>> Yes.  Actually, N+1/2 gear apart, so they don't need to be close to each
>> other.
>>    
>
> Actually, the sensors need to be an odd multiple of 1/4 tooth apart; e.g.,
> 2.75 teeth or 4.25 teeth. Half a tooth would give you signals 180 degrees
> out of phase, not nearly as useful.
>
> -- Dave Tweed
>   Well, 1/4 of tooth+gap, anyway.  That is assuming tooth=gap, which may not be true.  One should be on the edge of a tooth when the other is in the middle of a tooth.  Or one on the edge of a gap when the other is in the middle of a gap, if the gap is smaller than a tooth.

Kerry

2011\10\17@045244 by slippyr4

picon face
Are you using one of these?
>
> http://www.allegromicro.com/en/Products/Categories/Sensors/ats.asp
>
>
Yes, ATS642. I made a tiny little potted board with a load resistor and a
comparator on it.

The target is indeed an ABS reluctor ring. The tooth-gap spacing is pretty
close to 50:50, as far as I can tell.

My single channel solution has been in use for some time now and has proven
to work very well. I just wondered if adding a second one (in the right
place, and that might be tough to do) would give me the directionality that
grey code provides

2011\10\17@093406 by Kerry Wentworth

flavicon
face
slippyr4 wrote:
> Are you using one of these?
>  
>> www.allegromicro.com/en/Products/Categories/Sensors/ats.asp
>>
>>
>>    
> Yes, ATS642. I made a tiny little potted board with a load resistor and a
> comparator on it.
>
> The target is indeed an ABS reluctor ring. The tooth-gap spacing is pretty
> close to 50:50, as far as I can tell.
>
> My single channel solution has been in use for some time now and has proven
> to work very well. I just wondered if adding a second one (in the right
> place, and that might be tough to do) would give me the directionality that
> grey code provides.
>   Shouldn't be that tough to do.  The second sensor can be anywhere around the wheel, as long as it is in the middle of a tooth (or gap) when the first one is right on the edge of a tooth (or gap).  And it doesn't need to be perfect, although the closer it is, the faster the gear can turn without losing counts.

I haven't actually used the sensors in question, but I built the machines that test them.

Kerry

2011\10\17@153517 by Electron

flavicon
face

At 15.32 2011.10.17, you wrote:
{Quote hidden}

Sorry, I missed some posts: is this to know if the wheel is going into a
forward vs backward direction?


>I haven't actually used the sensors in question, but I built the
>machines that test them.
>
>Kerry
>
>

2011\10\18@061515 by slippyr4

picon face
Yes.

On 17 October 2011 20:34, Electron <RemoveMEelectron2k4KILLspamspaminfinito.it> wrote:

{Quote hidden}

> >-

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