On Thu, 20 Aug 2009 12:00:45 -0500, you wrote: >Chris Radek wrote: >> (I don't recommend any of this. Getting a suitable encoder or >> suitable hardware to read the existing one is so much better.) >> >> >Yes, a slight fudging of the encoder signals to keep within software >range might be OK, but the extreme case presented by the >OP is so FAR away that it seems like one of those "will never work" >situations. If I remember the numbers right, he is about 4.44 >times to slow to track the quadrature counter at 1000 RPM. His reading >of losing track at ~200 RPM also indicates that is the right figure. >Some people might be OK with threading at 200 RPM, but once you have >CNC, there's no need to restrict yourself to that.
One reason it's far too slow is the totally unrealistic base period. 62500 is way too slow, reading the integrator manual, it probably should be much nearer 25000. >Either a hardware encoder counter or a MUCH lower-resolution encoder is >the solution. (As a seller of hardware encoder counters, I may be >biased as to the correct solution to this problem.......) I've the 500 PPR Stegmann and a Heidenhain 125 ppr to try, unfortunately the 125 is a sinusoidal encoder, maybe the line drivers can sort that, I'll find out at the weekend. As for dividing encoder counts, it's a perfectly valid solution. There are several commercial dividers, the US Digital one pointed out here, being by far the cheapest. Stegmann even make an encoder with a pulse divider built in (DRS61 series 1-8192 PPR). Steve Blackmore -- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
