On Tue, 2008-08-05 at 20:16 -0500, Jeff Epler wrote:
> To accurately read a quadrature signal you must sample it frequently
> enough that there is absolutely never more than one input transition
> per
> sample.
> 
> Say that your machine has an 8000ns jitter at a 20000ns nominal
> base-period.  This means that if you sample at T=0 then the next
> sample
... snip
>  Most operating systems will have no
> more than a few hundred task switches a second, and users typically
> cannot notice when those switches are delayed or advanced a few
> milliseconds.
> 
> Jeff

On Tue, 2008-08-05 at 20:19 -0400, Sergey Izvoztchikov wrote: 
> Is there an issue of EMC2 not being able to keep up with hardware ? 
> What is typical frequencies involved with servo based CNC systems, 
> where EMC2 is used to close the loop ? Could more powerful computer 
> help in this case ?

(This answer got a little more involved than I had planned, corrections
are welcome.)

As Jeff pointed out in detail, there a two ways to handle encoder input.
Either with the parallel port inputs and EMC2 encoder software, or with
encoder hardware, usually on an FPGA card (parallel port or PCI), that
then passes the encoder solution to EMC2. Since the hardware is purpose
built, it is much faster. 

For the speed issue, you might think of reading an encoder being like
when you are expecting a telephone call. If you check every minute, to
see if the telephone is ringing, the phone might ring for close to a
minute before you you check it. If you check every thirty seconds then
you will get to a call faster. If you check every five minutes and the
phone rings for only a minute before it stops ringing, then you could
miss the call all together. Checking sort of maybe around every minute
(jitter?) you may or may not miss a call. So the maximum speed the
encoder can send you pulses is a combination of how fast, and how
regularly you can check for the pulses. On the other hand, checking
faster than you need to just wastes processing resources. For EMC2's
software encoder (actually decoder?), the checking speed is set by
the .ini file base-period setting which is a combination of how fast the
computer is and how much other stuff the software needs to do. For a
hardware encoder the speed is set by the FPGA firmware.

Since the encoder speed and the motor, are linked together (by the fixed
ratio of encoder pulses per motor revolution), the overall axis speed
can be no faster than the slower of the two. Maximum motor speed is
determined by the motor voltage and load (axis mass and friction).

As with the encoder, the motor control PWM pulses can be done in
software or hardware, again with hardware (FPGA) generally being faster.
The PWM signal is more like a series of on pulses or periods followed by
a series of off pulses or periods with the total number of periods per
cycle fixed at a certain number. The value of the PWM signal is
determined by the number of consecutive on periods compared to
consecutive off periods. If you have two on and eight off, the value is
20% of the full value. Like checking to see if the phone is ringing, a
PWM cycle is built by checking at each period to see if a period needs
to be on or off. How often and regularly you can check will determine
how fast the PWM cycle can be. Another issue with PWM speed is that the
cycle speed is determined by both the period speed and the number of
periods in a cycle. The ten period per cycle example above, can be
considered ten times faster than a one hundred period cycle, but the
possible values are only 0, 10, 20, 30 ... 90,and 100%, whereas the one
hundred period cycle values are 0, 1, 2, 3, ... 99,and 100%. Higher
numbers of periods per cycle, or higher resolution, makes tuning easier,
but takes more time. So the maximum PWM speed is a combination of period
time and cycle resolution. Off hand, I am guessing that for software PWM
the minimum period is determined by the base-period setting and the
maximum resolution by the servo-period.

My brain hurts so I'll stop here.

-- 
Kirk Wallace (California, USA
http://www.wallacecompany.com/machine_shop/ 
Hardinge HNC/EMC CNC lathe,
Bridgeport mill conversion, doing XY now,
Zubal lathe conversion pending
Craftsman AA 109 restoration
Shizuoka ST-N/EMC CNC)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to