Post by thread:[PIC]: Stumped by rotary encoder

[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 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Re: >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. Salvo(TM), The RTOS that runs in tiny places(TM) Pumpkin, Inc. 750 Naples Street San Francisco, CA 94112 tel: (415) 584-6360 fax: (415) 585-7948 web: http://www.pumpkininc.com email: spam_OUTaekTakeThisOuTpumpkininc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

SkinTech wrote: {Quote hidden}> >[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 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 01:39 PM 7/22/01 -0400, you 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! 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

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 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

At 09:38 AM 7/23/01 -0400, you wrote: >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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi Jan. (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 Regards, -- ______________________________________ Andrew E. Kalman, Ph.D. aekspam_OUTpumpkininc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I think I found an active link but must admit I've never seen the original .... www.utad.pt/~digital2/Apoio/Software/PICS/Pic_Aplications_Notes/Paralax_ pic_apps.pdf Rotary encoders appear to be "Note 4" beginning on page 23. Hope this helps. Cheers, Kevin >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 7/23/2001, 11:10:26 AM, "Andrew E. Kalman" <@spam@aekKILLspamPUMPKININC.COM> wrote regarding Re: [PIC]: Stumped by rotary encoder: {Quote hidden}> Hi Jan. > (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 > Regards, > -- > ______________________________________ > Andrew E. Kalman, Ph.D. RemoveMEaekTakeThisOuTpumpkininc.com > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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 <spamBeGonedwaynerspamBeGoneplanet.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.

Both of these documents are identical although TechTools has done a global replace of the word Paralax and replaced it with TechTools. I wonder what the original document looked like? It had 85 pages occuring before this content. John Dwayne Reid wrote: {Quote hidden}> > 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) | \====================================================================/ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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 ProgCCW ;do the processing work here goto EncUpdate ProgCW ;do the processing work here EncUpdate movfw NewEncCmd movwf CurEncCmd ;update present enc positions ExEncInput return part 3 136 bytes -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservEraseMEEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

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 SkinTech wrote: {Quote hidden}> 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 -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservspam_OUTKILLspammitvma.mit.edu with SET PICList DIGEST in the body