Kirk, I kind of understood some of it, but with your explanations it's more clearer now. I think there should be formula or algorithm, which would allow based on RPMs of the motor or its voltage and amperage to calculate optimal frequency of reading from encoders, and this in turn will allow to calculate how often software should sample encoders. Is that right ? Looks like finishing this design would require quite a lot more things to be work out. Many more than we initially thought.
Jeff's explanation suggests there could be a limit related to computer OS and overhead of switching tasks in Intel's CPUs would be one of the limiting factors. So it's important to know if software will be able to keep up. Jon, Are the signals from encoders routed "as is" to EMC2 to decode or there is a "logic" in your hardware which does partial or full decoding before handing signals back to EMC2 ? In design we're discussing here assumption was made that EMC2 would be able to decode encoder's signals and keep up with hardware. Doesn't look like it is always the case. Is the speed of CPU context switches a limit here or actually speed of parallel ports or PCI controller cards, or both ? On Tue, 2008-08-05 at 20:52 -0700, Kirk Wallace wrote: > (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 ------------------------------------------------------------------------- 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
