Gene Heskett wrote: > Sure there is Jon. Timestamp the last 4 edges so you can develop an > average speed over the total time period of those 4 stamps. Sounds great at first, but then you are basing the control loop on past history, which makes it even slower to respond to what is happening NOW. Sure, it will smooth out the growling due to a very coarse encoder, but it is a real compromise. > Then add the > last few digits for the position it is expected to be at the servo threads > time. The only thing to complicate that would be a motion reversal within > that 4 sample period. > Yup, that would foul things up a lot, if you ever want to do rigid tapping. The reversal would be seriously smoothed out and you might break taps or mangle the threads. > Or maybe I don't fully appreciate the problem. No explanation offered so > far seems to explain why the encoders rps output, at a mechanical speed of > 20 rps, has +- 3.xxx or more from the 20 its actually doing, flickering in > the halmeter output. And this 'noise' does not seem to be all that much > effected by the actual speed regardless of the speed as long as its over > about 1 rps. > Well, every sample period will have a guaranteed +/- 1 count jitter. And, they are correlated, so if the extra count is in this sample, then the next one will probably be short one count. So, that explains jumps of +/- 2 counts between adjacent samples. Yes, this jitter of +/- 1 count per sample will remain constant and NOT scale with velocity, as it is a timing relationship between when the counts occur and when the position is sampled. So, I expect that part.
Now, I'm not too clear on the +/- 3 fluctuation in terms of REVOLUTIONS rather than COUNTS, which you seem to be saying above. I completely expect jumps of +/- 2 counts/sample, but that should be divided by the number of encoder counts/rev. If the measured speed is jumping by +/- 3 RPS, something seems to be really wrong. Can you look at the encoder velocity in count units? (That is ppmc.0.encoder.x.delta on pico systems boards.) This value DOES jump to zero for one sample whenever the encoder syncs to the spindle, by the way. The encoder velocity pin (scaled from counts to rotations/second for a spindle axis) is fudged, it retains the previous value for that one sample where velocity can't be known when the spindle syncs. And, finally, I think you may need to get an oscilloscope on the encoder outputs to see if they are picking up noise or possibly failing to follow the pattern on the encoder disc at higher speeds. If these sensors need a pull-up resistor, then possibly the value of that resistor needs to be changed. Jon ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
