Dave wrote: > So basically you could factor out the jitter entirely? > > That sounds like a really good idea! :-) > Well, you can't, really. You can only reduce the likelihood of the jitter affecting the calculations. The problem is that a thread can be interrupted at any point, without any way to tell exactly where the interrupt caused a delay. So, if you sample the timer here, and then sample the encoders THERE, you have no way to know for sure what the time difference between those two events is. If you disable interrupts between those two events, then you have bounds on the time difference, but we probably don't want to do that.
I don't know enough about the kind and duration of interrupts that might preempt the servo thread to make much of an evaluation, but the important thing is that those interrupts can happen at ANY point in the code, and trying to correct for it by taking one time sample at one point in the code could even make things worse! This sort of thing could be studied with a little test rig. You hook up a constant frequency source to an encoder counter, and use the CPU timer to attempt the correction as described previously. With a perfectly steady velocity, then any velocity jitter improvement will be due to the correction scheme. Jon ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
