On Fri, 30 Mar 2012, Charles Steinkuehler wrote: > Date: Fri, 30 Mar 2012 13:46:48 -0500 > From: Charles Steinkuehler <[email protected]> > To: EMC developers <[email protected]> > Cc: Peter C. Wallace <[email protected]> > Subject: Re: [Emc-developers] The preempt_RT vs RTAI question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/30/2012 12:19 PM, Peter C. Wallace wrote: >> I wonder for non software-step systems if a crude busywait from >> thread invocation till hi-res timer count match could be used to >> sacrifice some CPU for nS jitter times. > > Is there some reason the hardware isn't sampling counts, positions, > etc at fixed times to reduce the dependence on software polling > jitter, or am I missing something basic? I'm still wrapping my head > around the code...
Well currently LinuxCNC _is_ the timing source. This makes a lot of sense when you may have a mix of different (or no) special hardware. If the hardware does the timing it has to become the timing master which makes a much more hardware dependent system. I have considered a DPLL in the hardware to do timing (effectively a jitter filter) but still leave the servo thread invocation as the master clock. But this ends up amounting to something very similar as I proposed earlier, that is, at servo thread invocation wait until the actual start time (which is TMAX_Jitter beyond the nominal thread activation time) Or as I mentioned before, let the lower levels of the control loops use the actual thread invocation times for their calculations. As an aside, our older firmware before HostMot2 was capable of hardware timing that is PWMFreq/N --> host interrupt+latch counters. This feature was never used by LinuxCNC however. > > I do real-time on Windows, with no kernel patches! :) It is at a > slower basic rate (a video field is apx. 15 mS), but I'm quite certain > that our latency jitter is much more than 15x the values being > discussed for RTAI. I probably have more than 5 uS jitter just in > arbitration for the PCIe bus so I can _send_ an interrupt to the > system processor (the system supports lots of DMA streams, and I'm > pretty constantly moving around 500 MBytes/s or so of data in each > direction). > > I understand the importance of the latency jitter spec for folks > generating pulses via software, but it seems like it should be fairly > insignificant for hardware assisted control. > Yes and no, as an extreme example, consider a velocity mode drive moving at 5 IPS, (.005" per thread invocation) if you are 200 uSec late on a 1 ms servo thread, the PID loop will see a bogus .001" position error (which is really a time base error) and attempt to correct it (causing a real error) > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk91/5gACgkQLywbqEHdNFysqgCg5VgjCOKlC2a3ML0FOhIRdpfa > JSQAmwftKRZ8xJke3QyrLYNbXQS9SBfd > =e/gb > -----END PGP SIGNATURE----- > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
