I believe that hunting is a natural process for a digital servo system. Most industrial servos use high resolution encoders - oftentimes 2500 ppr which in quadrature is 10,000 counts per rev. Finer seems to create less digital hunting - chatter or buzzing as the motor looks for the correct position.
The latency in those encoders might be an issue at high servo update rates > 1 khz. In the FAQ they do talk about how the index signal can be corrupted by high magnetic fields and they mention stepper motors as a possible problem. Still these are so inexpensive compared to everything else they would be worth a shot. How do these compare to some of US Digital's low cost encoders? I've purchased a fair amount of other equipment from US Digital and I have been happy with their service but I have no experience with their miniature encoders. Dave On 1/13/2010 3:36 AM, K.J. Kirwan wrote: > And here are links to those Digi-Key pages: > > The encoders: > http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=us&keywords=AMT102-V%20KIT > http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=us&keywords=AMT103-V > > And the "lump" line driver cables (which you will almost certainly want): > http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=us&keywords=CUI-102E-10 > http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=us&keywords=CUI-103E-10 > > And the "lump" line driver cable data sheets (such as they are): > http://media.digikey.com/PDF/Data%20Sheets/CUI%20Inc%20All%20Brands%20PDFs/CUI-102E-10.pdf > http://media.digikey.com/PDF/Data%20Sheets/CUI%20Inc%20All%20Brands%20PDFs/CUI-103E-10.pdf > > (BTW, those "lump" line drivers are pretty cheap, > and might come in handy anywhere any single-ended > TTL encoder needs a quick-and-dirty conversion to > differential line drivers. Just cut off the socket > and wire the "lump" to whatever you like. Viola!) > > As far as resolution, they are all the "same", > in that they are DIP switch selectable in 16 steps > from 48 PPR (30000 RPM) to 2048 PPR (7500 RPM), > in both binary and decimal resolutions, > as per this table: > http://media.digikey.com/pdf/Data%20Sheets/CUI%20Inc%20All%20Brands%20PDFs/DIP_switch_settings.pdf > > I would guess that the finer settings might exhibit hunting more? > And that decimal settings might hunt more than binary settings? > > Dewey, what resolution are you using? > Are you using only quadrature counting? > Have you observed any hunting while quadrature counting? > Have you ever tried using single-phase counting and > did you ever see any extra counts? > How many different resolution settings did you try if > you ever went looking for hunting or extra counts? > > Again, the "extra" counts (if any) are not supposed to be a > problem (numerically, at least) as long as they are counted > using the quadrature method. The jury might still be out on > position-servo-loop closure, which is why I am trying to > gather information from those who have actually used them. > > For those on the list who have more machining background and > maybe a little less electronics background, what we are > talking about here is that if you take any traditional > optical encoder and a CUI AMT-102-V (or CUI AMT-103-V) > capacitive encoder, both with the same resolution, and > rotate them both (very, very slowly)... > > The optical encoder will count like this: > Zero... > One... > Two... > Three... > Four... > Five... > > But the AMT-102-V might(?) count like this (balanced?): > Zero... > One... > TwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThree > TwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThree > Four... > Five... > > Or it might(?) count like this (unbalanced low?): > Zero... > One... > TwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThree > Three... > Four... > Five... > > Or it might(?) count like this (unbalanced high?): > Zero... > One... > Two... > TwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThreeTwoThree > Four... > Five... > > (Digital logic experts please note that I am not saying > anything special about the two-three transition, I just > picked it at random for convenience in this example.) > > And if the counting business isn't bad enough already, > it might be affected by how eccentric the shaft/disc is > relative to the body. (Remember, this is a kit-type > encoder, it has no built-in ball bearings.) So there > might be an error variance that repeats every 360 degrees. > > Servo loop experts might be driven nuts by this, or they > might just say widen the deadband and live with it. But > that might not make the problem go away completely when > the following error is near the upper limit, because you > can't be sure (or can you?) when you'll hit another > hunting spot. Or maybe the problem appears worse when > following error is very small? > > Anyway, for those who are still following this thread, > sorry if I've beaten the subject to death, but a low-cost > encoder might be a good idea, provided it doesn't come > with a whole new set of gotcha's; which is why I'm so > interested in hearing from those who have actually used > them, especially in a position servo loop. > > So I'll take any information I can get, and I can take > this off-list if everyone is tired of it. > > Thanks, > > Kim > > > Jeff Epler wrote: > >> On Tue, Jan 12, 2010 at 08:47:28AM +0200, Roland Jollivet wrote: >> >> >>> What's the resolution etc. of your encoder, and what did it cost? >>> >>> They seem reluctant to simply list pricing. >>> >> >> I don't know about pricing direct from CUI, but digikey sells them >> starting at single quantity and will happily display the price ($29.95 >> qty1, on down to $18,900 for 1000 of them). >> >> Jeff >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users