On Fri, 02 Oct 2009 12:37 +0100, "Steve Blackmore" <[email protected]> wrote:
> > I've redone that at 100 rpm, and out of interest looked at the pulses > out for the Z axis, the position interpolation is linear, as shown in > halscope, the pulses out are anything but! Surely they should be linear > too? > > There are several screenshots so I bundled them into a pdf. > > On page 6 I changed the sampling rate to base thread. > > http://filebin.ca/wacbfm/screenshots.pdf > > Steve Blackmore > -- The last screenshot is the good one (it is the only one that is zoomed in enough to see the details of the encoder signals). Problem #1: both the dark blue and the green encoder traces have numerous glitches. Most of the time those glitches will simply result in one count up followed by one count down, with no net change in position. But there WILL be a disturbance in the calculated velocity and possibly in the interpolated position (since it uses velocity to interpolate position between encoder pulses). And sometimes you might get unlucky and have a glitch that actually gets counted, which will cause a real net position error. The dramatic drop in velocity that happens about 3.2 divisions from the left of the screen coincides with the glitch on the green encoder trace - that glitch was probably interpreted as a count by the software. It is less clear what causes the two large velocity spikes about 6 divisions from the left. There are no corresponding glitches on the encoder signals. But keep in mind that the velocity is only updated every 1mS, and it reflects everything that happened in the preceding 1mS period. So those velocity spikes might be due to encoder noise that happened slightly earlier. There was a large burst of noise on the green encoder line before the first spike. You'd need to zoom in by about another factor of 10 to get a real look at the encoder signal glitches. If they are lasting only one base period, then software debounce as Andy Pugh has already suggested could work. However, that will limit the max count rate, and is at best a workaround. I'd recommend trying to deal with the glitches at the source, which is almost certainly in the hardware. Check the wiring, parport connections, shield grounds, etc, for places where noise could get in. Use an analog scope to probe directly on the inputs to the computer and see if there is any noise or crosstalk between the encoder channels, etc. Note that crosstalk spikes might be less than a microsecond long - use a two channel scope, trigger on one encoder channel and look at the other, with sweep speeds varying from slow enough to see a full encoder cycle all the way up to 100nS/div or so. I notice that the glitches only happen when the encoder signals are high. Maybe the encoder has open collector drivers and you need stronger pullups to overcome noise in the high state? Problem #2: the dark blue encoder trace has a duty cycle that clearly not 50% - probably more like 35%. In the normal x4 counting mode, the encoder counter looks at every edge, and calculates velocity based on the time between edges. The low duty cycle on the dark blue trace means that instead of seeing edges at 0%, 25%, 50%, 75%, and 100% of a full encoder cycle, the edges are happening at something like 0%, 20%, 50%, 80%, and 100%. If you ignore the large spikes and notches in the light blue velocity signal, there is a clear periodic pattern about one vertical division high which corresponds to that pattern. The rising blue edge, rising green edge, and falling blue edge are closer together than they should be, resulting in the velocity being too high. Then the falling blue edge, rising green edge, and rising blue edge are farther apart than they should be, so the velocity is too low. This is a perfect example of GIGO (garbage in, garbage out). The signals going into the encoder counter are bad, so the results coming out are also bad. Nothing downstream from there can possibly be right, so it doesn't even make sense to look at the step pulses coming out of EMC2. Fix the noise problems and the big spikes should go away. Fix the duty cycle (if you can) and the periodic variations should go away. If you can't fix the duty cycle issue, then use x1 counting. X1 counting only looks at a single edge of one channel and is immune to duty cycle errors (at the expense of having 1/4 the resolution). Hope this helps, John Kasunich -- John Kasunich [email protected] ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
