Peter C. Wallace wrote: > > Well 100 uSec of jitter should be perfectly acceptable _if_ the PID > (or hardware stepgen) corrections were based on actual time instead of > thread > invocation time, heck even 500 uSec jitter might be OK. Hmm, I don't know. Without velocity estimation, I'm not sure if the actual time is used in any way, I think it just uses the scheduled interval. With velocity estimation, part of the algorithm (at least) is based on a time stamp in the encoder counter, and so will not be affected by RT jitter. I worked on this last year and was fairly familiar with how it worked then, but now it is getting fuzzy. But, I think it doesn't make any other corrections for actual sampling time, although I'm pretty sure the information is available from rtapi. 500 us jitter is not going to be OK, as it will likely cause an overrun of the thread. Much better to leave plenty of headroom so the task never can overrun.
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
