On Sat, 14 May 2011, dave wrote: > Date: Sat, 14 May 2011 08:47:29 -0700 > From: dave <dengv...@charter.net> > Reply-To: EMC developers <emc-developers@lists.sourceforge.net> > To: EMC developers <emc-developers@lists.sourceforge.net> > Subject: Re: [Emc-developers] Fanuc converter > > On Sat, 2011-05-14 at 08:34 -0700, Kirk Wallace wrote: >> On Fri, 2011-05-13 at 20:23 -0500, Jon Elson wrote: >>> Kirk Wallace wrote: >>>> Is replacing the encoder with a more EMC2 friendly encoder an option? I >>>> have a couple motors with proprietary encoders on them that I plan on >>>> replacing with quadrature and Hall encoders or magnetic encoders such as >>>> the AEAT-6010 if it's fast enough. Removing the old encoders was easy >>>> enough and provides the mounting features for the new encoders. I >>>> haven't gone beyond a rough plan so far, so this may not work. On the >>>> other hand, if the price on Fanuc motors has gone up, it may be cheaper >>>> to use generic motors with EMC2 instead and use the Fanuc motors on >>>> Fanuc systems. >>>> >>> Oh, well, sure! You can always use the new AMT 6-channel encoder that >>> has commutation outputs along with >>> quadrature. BUT, the Fanuc serial encoders have 32K, 64K and 1 million >>> counts/rev, and that kind of resolution >>> is VERY expensive. These high-res encoders are probably more valuable >>> than the motors! >>> >>> I was thinking about this mostly for retrofits of machines which already >>> had these motor/encoders mounted >>> on the machine. There are quite a few of them out there. Some are the >>> older S series which I already have converters >>> for. They moved on to these serial encoders sometime in the mid 90's. >>> >>> Jon >> >> They must use direct drive, fast screws and very stiff mechanical >> structures in order to justify the high encoder resolution. On my >> machines, the least significant bits would be noise. > > That kind of resolution makes for nice velocity control at low speeds > where otherwise we end up with 0, 1 or 2 counts per a servo cycle. > > Dave >>
Timestamp based velocity estimation improves this quite a bit (the software encoder, Mesa and Pico systems encoders all have this feature) But the timestamp velocity estimation signal/noise is limited by quadrature error (inexact 90 degree quadrature) I see a very roughly 2x to 10x improvement in the velocity signal depending on encoder and speed using the timestamp. I'm not sure where the crossover is where higher resolution is better than the timestamp system but I suspect a 1 million count encoder is going to beat the timestamp system by a wide margin. > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
