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

Reply via email to