Re: Freqmod test result & Q

[Chris Wagner <clwagner-at-eecs.wsu.edu>]

On 30 Jun, Paul wrote:
> 
> 
> Hi Chris
> 
> There are three realtime tasks within freqmod where jitter may be expected -
> 
> The first is the pulse timing loop as defined by PERIOD.
> The second is set by CYCLE_TIME in TRAJ, typically 10mSec.
> The third is also CYCLE_TIME, but this time in the AXIS_n section. (Side 
> note: From reading emcmot.c, it would appear that only the parameter in the 
> last AXIS_n has any effect)
> 
> The interrupt latency that you have recorded by running the 
> rtai/testing/testsuite will affect the timing all three of the above tasks in 
> freqmod. It would be interesting to hear what sort of period you see the 
> "algorithmic jitter".

Hi Paul,

Hmm, I initially thought that there was a fixed period, now I see that
in fact the algorithmic jitter is feed-rate dependant.  I believe that
algorithm jitter is a natural consequence of having quantized time
resolution, and trying to output a frequency that is not a exact
multiple of the period.  For example suppose I command a frequency
(feed) that has a period 2.5 times the base period.  The synthesizer
seems to produce 2 cycles at a period of two followed by two cycles at a
period 3, thus on average it has a period of 2.5 cycles.  I don't see
how this effect can be avoided in a digital synthesizer.  I'm basically
at the limit of what I can measure with just a scope, if someone has a
logic analyzer or spectrum analyzer they could quantify the various
timings.

I feel that freqmod is running fine for me, I'll need to try motors to
see how it works.

On fixed hardware does steppermod run with a smaller base period then
freqmod? (my setup with steppermod is not currently operational)

-- 
Recreational Calculus - Just For Fun!

Chris Wagner
clwagner-at-eecs.wsu.edu