Jon Elson wrote: > John Kasunich wrote: >> The software encoder counter generates its velocity output by looking >> at not only how many counts arrived, but _when_ they arrived (with base >> period time resolution). I'm pretty sure the latest hostmot2 driver >> does the same - in that case it knows when pulses arrived with >> sub-microsecond resolution, and the velocity output can be very smooth. >> >> This image ( http://jmkasunich.com/pics/new-encoder.png ) shows the >> software encoder's velocity output (blue) compared to the actual >> velocity (green) and velocity calculated by differentiating the position >> (red). The improvement from red to blue is dramatic. The only time the >> blue trace shows any significant error is when the velocity is near >> zero, when many milliseconds go by with no counts at all. >> > Certainly does look nice, but you can't do this with a standard encoder > counter.
Define "standard counter". The whole idea behind FPGA based hardware is that you can do creative things that make your product better than the next one. Count+Timestamp counting of encoders isn't new - a former employer of mine was doing it in the early 1980's, and maybe before that. IMO, count+timestamp is (or should be) the "standard" for hardware encoder counting. > Wait a minute, your scope trace is 100 ms/div, or 100 default > servo cycles per div. So, I'm not sure this really does much different > than a hardware encoder counter. That image isn't about hardware counting. Hardware counting enables high count rates, which in turn lets you use high PPR encoders to reduce quantization noise. That scope trace shows a dramatic reduction in noise with a LOW PPR encoder. > If it does, I can't see it at this > time scale. You can't see the difference between the red and blue traces?! > Anyway, due to the limitations of communication rates to > external devices, I don't see a real easy way to improve upon such > hardware as I sell. Agreed - that is why I much prefer PCI attaached devices to EPP attached devices. > My encoder counter as it is really doesn't record > "more information to work with". One COULD put in a velocity counter, > but if it is only sampled once per servo cycle, there's no more info in it. I don't know what a velocity counter is. A timestamp register DOES provide more info, regardless of how often you read it. > I think (hope) something useful can be done without increasing the > sampling rate. It may well be that adding a smoothed velocity estimator > to the encoder counter circuit would be beneficial, and by running that > process at a higher clock rate in external hardware it could provide > less delay than a filter limited by the servo sample rate. I'm not sure > how much resources I can add to my FPGAs, but I know the register > address space is pretty maxed out already. Also, the time to read the > registers is already too long, I don't want to add any more data to read. My approach to the "ideal encoder counter" is to allocate the register space between counts and timestamp. Unfortunately there is no single split that is ideal for all systems. The timestamp needs to be big enough that it doesn't roll over twice between reads - a slower servo period requires a bigger timestamp register or a slower timestamp clock. The counter also needs to be big enough that it doesn't roll over twice between reads - a slower servo period needs either a bigger count register or a lower maximum count rate. If you are expecting very high count rates, you make the counter portion of the register wider, and slow down the timestamp clock. At high count rates, you can get decent velocity data using only the counts, so the timestamp resolution is less critical. On the other hand, if you have low count rates, you need all the help you can get to smooth the velocity, so you shrink the count register and use a faster timestamp clock for better resolution. In a PCI system, the overall register size would naturally be 32 bits. Assume a maximum servo period of 10mS (1/10 as fast as EMC's default, but lets give the user some flexibility). Assume a maximum count rate of 1MHz. That means a maximum of 10,000 counts between reads. In theory a 14 bit (16384 count) counter would do, but in practice rollover detection and handling is MUCH simpler if you add one more bit. So use 15 bits for the count. That leaves 17 bits for the timestamp. You could use a 10MHz timestamp counter, since the 17 bit timestamp would roll over every 12.8uS. Rollover detection in the timestamp register is much simpler, since it only counts up. In practice, I'd probaby do a 16/16 bit split. Having 100nS resolution on the timestamp is overkill, while adding a bit to the counter would allow either a higher max count rate or a longer sample interval. If you are limited to 24 bits, you need to make a slightly more difficult compromize, but it still works well. If you use a 1MHz timestamp clock, and limit the encoder count rate to 500KHz, you can split the register into 12 bits for timestamp and 12 bits for count. That would require reading the registers at least every 4mS, which still supports EMC's 1mS default with plenty of margin. If you can only transfer 16 bits, then things get a lot tougher. If you want a 1mS sample rate and intend to count at 300KHz, you need a bare minimum of 9 bits for the counter, and should really use 10 bits to avoid ambiguity on rollovers. That leaves 6 bits for the timestamp. So the timestamp clock would be no more than 64KHz. The result would be a velocity quantization of 1.6% at low speeds, improving to <1% as the count rate increases. Those numbers are a couple orders of magnitude better than the 100% quantization error that happens with "counts only" at low speeds (roughly 1 count per servo period). Regards, John Kasunich ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
