Sebastian Kuzminsky wrote: > Jon Elson wrote: > >> A problem with EMC2 using the PID hal component is that the D term has >> no filtering on it. Due to the "double quantized" nature of encoders, >> there is a real spike in the frequency spectrum of the velocity at 1/2 >> the sampling rate. I call it double quantized because position is >> measured in discrete counts, and then the count is sampled at regular >> intervals. So, it is guaranteed that at certain velocities you will get >> a +1 / -1 jitter in the number of encoder counts per sampling interval. >> > > It's true that a digital system (such as a computer) estimating an > analog value (such as encoder velocity) always quantises to some extent, > there are things you can do with encoder counting that result in > significantly less quantisation error. > > If the encoder counter can timestamp the arrival of the encoder edges > with a temporal resolution that is high compared to the servo cycle > period, then the velocity can be accurately and smoothly estimated at > any (constant) velocity, from much less than one edge per servo cycle up > to the max practical edge rate. > > sampling jitter is not the problem. In some systems with relatively low encoder resolution, there are just a couple counts per servo cycle. So, the +1 / -1 nature of the sampling interval necessarily adds a "noise" to the perceived velocity. "Estimating" means filtering, as far as I can see. > >> If the encoder resolution is very high (I have 128,000 counts/inch on my >> minimill) it somewhat masks this. At lower encoder resolutions, the >> problem grows. Imagine a system where you are moving at 500 >> counts/second. With a sample rate of 1000/second, then the samples come >> up like this : 0, 1, 0, 1, 0 etc. That is a 100 % jump from sample to >> sample at 500 Hz. >> > > The "Reciprocal Time Estimator" solves this problem. See section 14.2 > of this paper: > > <http://repositories.cdlib.org/its/path/reports/UCB-ITS-PRR-95-3/> > I'll have to look at this. But, a quick scan shows you need to analyze the arrival time of each encoder count. My current external hardware doesn't do this, and may not have the FPGA resources to do it. With several hundred units in the field, I'm hoping for a solution that can work with the existing hardware.
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
