[sorry, send at first without tag. therefore resend]
Hi all,
I always try to solve my own problems (I learn from it) but this one has me
stumped.
My project has a 16F74, reading the output of a rotary encoder (2 bit), see
below.
First I check by polling if there is a change in the 'A' bit. If so, I wait
some 10mS (debounce) and then look again. If there is still a change, I
check if it is 1>0 or 0>1. In each case, I then check the 'B' bit to
determine direction. For debugging I beep once (CW) or twice (CCW) the
buzzer.
When turning the encoder I get seemingly random results. Sometimes it beeps
3 times, or 4 times, or 1 time, or not at all over half a revolution. Then
it starts again. I'm pretty sure it has to do with the debounce, but I can't
get it right. I must add that the beep adds another 10 or 30 mS delay
between pollings.
The encoders are spec'd at <5mS chatter.
Has anyone experience with decoding rotary encoders? Any help or ideas would
be greatly appreciated.
Jan Didden
SkinTech
; This is how I think the encoders work:
;The encoders output a 2-bit value:
; the A-bit signals rotation,
; the B-bit signals the direction of rotation. (actually A and B are interchangable of course)
; encoder movement is detected by polling PORTB and debouncing.
;
; --------------------->cw
; channel A ___ ___ ___ [channel A leads channel B]
; ___| |___| |___|
;
; channel B ___ ___ ___
; |___| |___| |___|
;
;
;
; CCW: channel A ___ ___ ___ [channel A trails channel B]
; ___| |___| |___|
;
; channel B ___ ___ ___
; _| |___| |___|
;
; A-bit B-bit Direction
; 0>1 0 CW
; 1 CCW
; 1>0 0 CCW
; 1 CW
>Has anyone experience with decoding rotary encoders? Any help or ideas would
>be greatly appreciated.
Parallax has a great App Note (Note 4) on how to read rotary encoders
using a "read, shift and XOR" algorithm. I helped put it in place for
a customer, with great results.
Note 4 includes assembly code for the PIC16.
Regards,
--
______________________________________
Andrew E. Kalman, Ph.D.
>
>[sorry, send at first without tag. therefore resend]
>
>Hi all,
>
>I always try to solve my own problems (I learn from it) but this one has me
>stumped.
>My project has a 16F74, reading the output of a rotary encoder (2 bit), see
>below.
>First I check by polling if there is a change in the 'A' bit. If so, I wait
>some 10mS (debounce) and then look again. If there is still a change, I
>check if it is 1>0 or 0>1. In each case, I then check the 'B' bit to
>determine direction. For debugging I beep once (CW) or twice (CCW) the
>buzzer.
>When turning the encoder I get seemingly random results. Sometimes it beeps
>3 times, or 4 times, or 1 time, or not at all over half a revolution. Then
>it starts again. I'm pretty sure it has to do with the debounce, but I
>can't
>get it right. I must add that the beep adds another 10 or 30 mS delay
>between pollings.
>The encoders are spec'd at <5mS chatter.
>
>Has anyone experience with decoding rotary encoders? Any help or ideas
>would
>be greatly appreciated.
>
>
>Jan Didden
>SkinTech
>
>; This is how I think the encoders work:
>;The encoders output a 2-bit value:
>; the A-bit signals rotation,
>; the B-bit signals the direction of rotation. (actually A and B are
>interchangable of course)
>; encoder movement is detected by polling PORTB and debouncing.
>;
>; --------------------->cw
>; channel A ___ ___ ___ [channel A leads channel B]
>; ___| |___| |___|
>;
>; channel B ___ ___ ___
>; |___| |___| |___|
>;
>;
>;
>; CCW: channel A ___ ___ ___ [channel A trails channel
>B]
>; ___| |___| |___|
>;
>; channel B ___ ___ ___
>; _| |___| |___|
>;
>; A-bit B-bit Direction
>; 0>1 0 CW
>; 1 CCW
>; 1>0 0 CCW
>; 1 CW
>
>--
Unless you're working with a *very* coarse encoder, there are probably a lot
more transitions happening than you might realize.
The 10 mS debounce is probably a bit much and may be contributing to the
problem. I would expect that 5 mS or so would be sufficient. This would
depend a great deal on whether you are using the encoder for position
sensing (more debounce) or for speed sensing (less debounce).
Another thing you might try is to remove your beeper timing from the
program. If you can trigger a one-shot (a 555 timer or such) to time your
audible feedback, then that complication (and timing uncertainty) will not
be adding to your debugging task.
(BTW, there was a suggestion on the [EE] thread to ignore the 1->0
transition on the A channel. Be aware that doing so will reduce your
resolution by half. Since you are ignoring B channel transitions and using
it as only a direction bit, you have already reduced your available
resolution by half. Depending on your application, this may or may not be a
problem.)
Regards, Bob
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>(BTW, there was a suggestion on the [EE] thread to ignore the 1->0
>transition on the A channel. Be aware that doing so will reduce your
>resolution by half. Since you are ignoring B channel transitions and using
>it as only a direction bit, you have already reduced your available
>resolution by half. Depending on your application, this may or may not be a
>problem.)
I don't think there is much percentage in double-counting between detents!
What I usually do is set up a state machine which ignores repeated transitions
on either input. You have to sample relatively fast, because the motion is
not smooth, it "jumps" between detents, and if you look at the specs for
the phase difference on a typical encoder it is not guaranteed to be
very large...
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam@spam@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Is this a mechanical encoder? Really long signal lines? I don't understand
why you are having to deal with bounces. The encoders I've used had clean
outputs.
Spehro Pefhany wrote:
>
> >(BTW, there was a suggestion on the [EE] thread to ignore the 1->0
> >transition on the A channel. Be aware that doing so will reduce your
> >resolution by half. Since you are ignoring B channel transitions and
>using
> >it as only a direction bit, you have already reduced your available
> >resolution by half. Depending on your application, this may or may not be
>a
> >problem.)
>
>I don't think there is much percentage in double-counting between detents!
>
Agreed. The whole notion of mechanical detents (and such a limited number of
discrete steps) wasn't contained in the original posting. My comments would
be much more applicable to an optical encoder with no detents and a much
finer resolution than appears to be the case here.
>What I usually do is set up a state machine which ignores repeated
>transitions
>on either input. You have to sample relatively fast, because the motion is
>not smooth, it "jumps" between detents, and if you look at the specs for
>the phase difference on a typical encoder it is not guaranteed to be
>very large...
>
I completely agree on the use of a state machine but I have to wonder what
your definition of a 'typical' encoder is.
It would seem that among the different types of encoders available, there is
a wide variation in what the specs of a typical encoder would be.
The optical encoders that I work with have hundreds of steps per revolution,
no detents, and plenty of phase difference between the channels. This
application has detents, limited steps, and the phase difference may be open
to question. Without being more specific as to the type of encoder, I'm not
sure that there really is such a thing as a typical encoder.
Regards, Bob
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>I completely agree on the use of a state machine but I have to wonder what
>your definition of a 'typical' encoder is.
Yes, I was speaking in the context of the OP, or IOW, a typical
*mechanical* shaft encoder used for manual setting. Of course the
state machine can be implemented in software or hardware.
>It would seem that among the different types of encoders available, there is
>a wide variation in what the specs of a typical encoder would be.
Agreed! Even on a high-speed encoder as used in motion control, I think
it's worth looking at the phase difference though, as it directly affects
the timing, particularly if software is being used.
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Well, these encoders are spec'd with <5mS chatter or bounce. I don't want to
process a change, then poll again, finding a change that really is the same
one with the contacts still not settled and bouncing between 0 and 1.
Therefore I tried a debounce delay after detecting a change, and after the
delay checking if the same change is still there. After all the feedback
from you all good people, I will now try to process after first sign of
change, then delay for next polling.
This may be a little off course of the basic conversation but, I use a LOT of
quadrature optical encoders (incremental type) in motion control
applications. So far I have been purchasing off the shelf, proprietary
motion controllers however, I would like to be able to use the PIC for the
controller and have it read the encoder which at most would be around 25 kHz
in frequency. I am using the PicBasic Pro compiler and am just starting to
learn assembly code for the PIC. I think the compiled code will run fast
enough. But, has anyone actually written code in the PicBasic language to
read a quadrature encoder reliably, and if so, could you post it on the list
for me to take a look.
Also, I would like to be able to use the PIC as a PLC. Is it possible to do
both in a single PIC or would one need to use separate PICs for each
application.
Any help will be greatly appreciated. I am sure you can tell I am fairly new
to the PIC scene.
Regards,
Randy Abernathy
4626 Old Stilesboro Road NW
Acworth, GA 30101
Phone / Fax: 770-974-5295
E-mail: .....cnc002KILLspam.....aol.com
We specialize in service, installation and repair of industrial woodworking
machinery
(I'm sending this to the list because a private email I sent you has bounced)
Re:
>Thanks a bunch! I searched the parallax site but the only thing I came up
>with was an app note written in BASIC. Not sure that is the one you mean.
>It's clear enough, but if you have a pointer to your specific PIC app note
>that would be appreciated.
Yes, it no longer seems to be there. It was a part of the Parallax
"PIC16Cxx Applications Handbook 1.1". A google search finds many
mentions of this handbook, but no active links ...
Why don't you email them directly and see if it's still available? I
downloaded it as a .pdf file long ago, and it does not appear to be
on any hard disk here. They had source on their web site, too --
RD_ENCDR.SRC.
O/wise contact me privately with an email address I can respond to --
At 10:13 -0700 07/23/2001, Internet Mail Delivery wrote:
>Your message cannot be delivered to the following recipients:
>
> Recipient address: EraseMEjan.diddenspam_OUTTakeThisOuTskintech.be
> Reason: Illegal host/domain name found
> (I'm sending this to the list because a private email I sent you has bounced)
> Re:
> >Thanks a bunch! I searched the parallax site but the only thing I came up
> >with was an app note written in BASIC. Not sure that is the one you mean.
> >It's clear enough, but if you have a pointer to your specific PIC app note
> >that would be appreciated.
> Yes, it no longer seems to be there. It was a part of the Parallax
> "PIC16Cxx Applications Handbook 1.1". A google search finds many
> mentions of this handbook, but no active links ...
> Why don't you email them directly and see if it's still available? I
> downloaded it as a .pdf file long ago, and it does not appear to be
> on any hard disk here. They had source on their web site, too --
> RD_ENCDR.SRC.
> O/wise contact me privately with an email address I can respond to --
> At 10:13 -0700 07/23/2001, Internet Mail Delivery wrote:
> >Your message cannot be delivered to the following recipients:
> >
> > Recipient address: KILLspamjan.diddenKILLspamskintech.be
> > Reason: Illegal host/domain name found
At 11:10 AM 7/23/01 -0700, Andrew E. Kalman wrote:
Why don't you email them directly and see if it's still available? I
>downloaded it as a .pdf file long ago, and it does not appear to be
>on any hard disk here. They had source on their web site, too --
>RD_ENCDR.SRC.
I stuck the above file name into Google and came up with 2 active links:
>
> At 11:10 AM 7/23/01 -0700, Andrew E. Kalman wrote:
> Why don't you email them directly and see if it's still available? I
> >downloaded it as a .pdf file long ago, and it does not appear to be
> >on any hard disk here. They had source on their web site, too --
> >RD_ENCDR.SRC.
>
> I stuck the above file name into Google and came up with 2 active links:
>
> http://www.tech-tools.com/files/picapp.pdf
>
> http://www.utad.pt/~digital2/Apoio/Software/PICS/Pic_Aplications_Notes/Paralax_pic_apps.pdf
>
> Hope this helps!
>
> dwayne
>
> Dwayne Reid <TakeThisOuTdwaynerEraseMEspam_OUTplanet.eon.net>
> Trinity Electronics Systems Ltd Edmonton, AB, CANADA
> (780) 489-3199 voice (780) 487-6397 fax
>
> Celebrating 17 years of Engineering Innovation (1984 - 2001)
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> Do NOT send unsolicited commercial email to this email address.
> This message neither grants consent to receive unsolicited
> commercial email nor is intended to solicit commercial email.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways. See http://www.piclist.com/#archives for details.
--
/====================================================================\
| John Voth Mobiltex Data Ltd.Calgary, Alberta,Canada, T1Y-4T7 |
| RemoveMEjvothTakeThisOuTmobiltex.com 403-291-2770, 403-259-6795 (fax) |
\====================================================================/
part 1 544 bytes content-type:text/plain; (decoded 7bit)
To all who provided advice on interfacing a rotary encoder:
Thanks very much, I got it working OK now!
The attached is the code fragment to detect movement and direction of an
encoder.
The key was the realisation that although these things bounce a lot, you can
start processing at the first change of state, and ignore the debounce as
long as you take care not to poll that encoder again within the next 5 mS or
so. After that time, the bouncing has stopped and it can be polled again.
Cheers, Jan Didden
part 2 2521 bytes content-type:text/plain; (decoded quoted-printable)
;--------System design notes-------------------------------------
;
; The encoders output a 2-bit value:
; the A-bit is used to detect rotation,
; the B-bit is used to determine direction of rotation.
; encoder movement is detected by polling PORTB.
;
; --------------------->cw
; channel A ___ ___ ___ [channel A leads channel B]
; ___| |___| |___|
;
; channel B ___ ___ ___
; |___| |___| |___|
;
;
; CCW<------------------------------
;
; channel A ___ ___ ___ [channel A trails channel B]
; ___| |___| |___|
; ; channel B ___ ___ ___
; __| |___| |___|
;
; A-bit B-bit Direction
; 0>1 0 CW
; 1 CCW
; 1>0 0 CCW
; 1 CW
;NewEncCmd holds the latewst polled PORTB inputs
;CurEncCmd holds the previously polled PORTB inputs
;There are 4 encoders, with the A-bits connected to PORTB and the A-bits to EncDirPort
;ProgA is one of the encoders we decode below
ProcEncInput ;decode encoder
movfw NewEncCmd ;new setting
xorwf CurEncCmd,W ;previous setting, W now has changed bits set
movwf EncChanges
btfsc EncChanges, ProgA ;prog enc change?
goto ProcProg ;yes, process it
goto ExEncInput
ProcProg
btfss NewEncCmd,ProgA ;if 1, was 0>1
goto ProgFall
ProgRise
btfss EncDirPort,ProgB ;if 0, was CW
goto ProgCW
goto ProgCCW
ProgFall
btfss EncDirPort,ProgB ;if 0, was CCW
goto ProgCCW
goto ProgCW
Hi-
Great, i may have a use for it. Just to note, you can double the resolution by
doing the same with the inputs (conceptually) reversed (ie polling B, and using
A to determine direction). With hand turned encoders this probably doesn't
matter, and in fact the lowere resolution might be beneficial (depending if
there are palpable detents).
Cheers, David
> To all who provided advice on interfacing a rotary encoder:
>
> Thanks very much, I got it working OK now!
> The attached is the code fragment to detect movement and direction of an
> encoder.
> The key was the realisation that although these things bounce a lot, you can
> start processing at the first change of state, and ignore the debounce as
> long as you take care not to poll that encoder again within the next 5 mS or
> so. After that time, the bouncing has stopped and it can be polled again.
>
> Cheers, Jan Didden
>
> ------------------------------------------------------------------------
> Name: encoder.txt
> encoder.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
pumpkininc.com
