John Kasunich wrote: > I have long had my own thoughts on this issue. Our software encoder > counter has a velocity output which is much less quantized than the > position output. Some (but not all) hardware drivers also have a > velocity output. If the PID loop had both position and velocity > feedback inputs, it could use the velocity feedback for the D term. > > This has the potential to be better than any filter - the encoder > counter (hardware or software) simply has more information to work with. > 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. 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. If it does, I can't see it at this time scale. 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. 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 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. Jon ------------------------------------------------------------------------------ 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
