Jon Elson wrote: > Andy Pugh wrote: >> Is there any reason not to use position-interpolated by default? > There might be. I don't know how position-interpolated works, but I > assume it might > introduce a delay in the position reports.
It does not introduce a delay. It uses the velocity between the last two edges to predict the position as time moves on, until the next edge arrives, at which point it uses that edge to correct any error in the prediction. Below is a halscope plot from when I was testing the interpolated output. http://jmkasunich.com/pics/interpolated-encoder.png This was over a year ago and I don't remember exactly what all the traces are. I believe I was using the simulated encoder component to generate a low-PPR test signal. The sine-wavey signal is the speed command to the simulated encoder - I wanted to simulate a spindle whose speed was varying under cutting load. The red is the normal position, taking rather coarse steps because it is a low PPR encoder. The light blue is the interpolated position. As you can see, there is no delay. In fact, the non-interpolated position can be said to have a "delay", since it sits at a constant level while the actual position is advancing, then jumps to catch up. The interpolated position is much closer to the actual. Regards, John Kasunich ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
