Sergey Izvoztchikov wrote: > 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, Sure, this is fairly simple. Current doesn't matter, but voltage does. If the motor is rated at 48 Volta, say, and your power supply is 36 Volts, then you'd get 36/48 * rated RPM. (This neglects drop in the servo drive and motor resistance, but gives a conservative upper bound.)
Encoder resolution can be described a number of ways, VERY confusing! Cycles/rev is the safest. You multiply by 4 to get quadrature counts per rev. Assume the voltage calculation above says you can get up to 1500 RPM, and the encoder has 500 cycles/rev, for 2000 quadrature counts/rev. 1500 RPM * 2000 count/rev = 3,000,000 counts/minute. divide by 60 to get 50,000 counts/second. This is at the very upper end of what a computer could safely read by software, but no problem for hardware encoder counters, either built in an FPGA or using such as the US Digital LS7166. You would want to sample this at least 100,000 times a second to be sure to not miss any transitions. and this in turn > will allow to calculate how often software should sample encoders. I may be a bigot, but I think software sampling of motor-driven encoders is a bad idea. You can do this with hand-driven encoders (MPGs) and for systems where the count rate is guaranteed to be slow, but when it gets into the tens of KHz then you are just asking for trouble. Of course, a fast, dedicated microprocessor can go faster than a PC with many tasks to work on. But, all that polling east up the micro's available resources, too. > 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 ? > The whole idea of the FPGA is to do all the time-critical stuff OUTSIDE the PC. So, there is a digital filter and a 24-bit bidirectional counters for each encoder channel. The HAL driver causes the 24-bit value to be latched (so it can't change while the individual bytes are being read) and it returns a 3-byte encoder count for each axis. There is additional hardware to handle the index pulses, if present. The Universal Stepper Controller and Universal PWM Controller also have counter devices that produce step pulses at varying rates, or constant rate pulses of varying width, respectively. The USC can go to a conservative 300,000 steps/second. The PWM controller produces 50 KHz pulses with 100 ns (now 25 ns on the new version) resolution. That is 1/2 % on the old ones, and 1/8 % on the new. I DEFY you to pull that off with software, even on a DSP. > > 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 ? > Kind of both. You can read the parallel port about every 800 ns, in theory. That would be a dedicated process that never let go of the CPU. A practical limit would be about 10 us (= 100 KHz) sampling on a fast CPU. And, it would eat up a huge amount of the CPU, maybe 50% or worse. Not a good use of the CPU, when a little hardware can do the job, and a dumpster CPU will then be enough. Jon ------------------------------------------------------------------------- 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
