On Mon, 23 May 2011, Javier Ros wrote:
Date: Mon, 23 May 2011 16:37:48 +0200
From: Javier Ros <[email protected]>
To: EMC developers <[email protected]>
Subject: [Emc-developers] Timestamp based velocity estimation. WAS: Re: Fanuc
converter
Hello,
In the referred thread, there was a reference to "Timestamp based velocity
estimation"
<quote>
Timestamp based velocity estimation improves this quite a bit (the software
encoder, Mesa and Pico systems encoders all have this feature) But the
timestamp velocity estimation signal/noise is limited by quadrature error
(inexact 90 degree quadrature) I see a very roughly 2x to 10x improvement
in
the velocity signal depending on encoder and speed using the timestamp. I'm
not sure where the crossover is where higher resolution is better than the
timestamp system but I suspect a 1 million count encoder is going to beat
the
timestamp system by a wide margin.
</quote>
I'm curious about the concept.
Could you please elaborate a bit or refer to some bibliography?.
This is hardware timestamp based velocity estimation. The most basic velocity
measurment from an encoder is (delta P)/ (delta T) where delta P is the change
in counts from the prevous sample period, and delta T is the servo thread
period. This works but suffers from major quantization errors at low speeds.
Imagine a 500 line encoder (2000 counts per turn) turning at 45 RPM, This will
generate a count rate of 1500 counts per second. If we sample this at a 1 KHz
servo thread rate, we will alternately get 1 and 2 count deltas. This will
in turn create alternate velocity estimates of 30 and 60 RPM which will create
noise and high frequency vibration.
This basic velocity estimation scheme can be improved by measuring the time
between counts with a timestamp. When we have the time between counts and the
counts, we still use (delta P)/(delta T) to estimate velocity, but now our
delta T is measured at a much higher resolution than the servo thread so the
velocity estimate has much smaller quantization noise.
I suppose that you are able to infer, within a realtime hal module, the
elapsed time between the actual invocation
and the previous one, and that that gives a real estimation of the thread
period, in comparison with the theoretical
value given in the ini file. Then you estimate the velocity as usual:
(new_pos - prev_pos) / (better_estimation_of_thread_period)
I supose that the parameters time and tmax of a function in a thread, for
example
pid.0.do-pid-calcs.time
pid.0.do-pid-calcs.tmax
are related to the implementation of such an algorithm.
But I can not find definitions for their meaning in the documentation.
How can I access these variables within a HAL module.
The only aparently related parameter I'm finding is period (and fperiod).
<quote>
6.4 Parameters
Comp?s are passed the "period" parameter which is the time in nanoseconds of
the last period to
execute the comp. This can be useful in comps that need the timing
information.
</quote>
<quote>
FUNCTION(name) Use this macro to begin the definition of a realtime function
which was previously
declared with "function NAME". The function includes a parameter "period"
which is
the integer number of nanoseconds between calls to the function.
</quote>
<quote>
fperiod The floating-point number of seconds between calls to this realtime
function
</quote>
What is the most appropriate way to find the elapsed time between calls of a
given function in a thread.
I'm presuming that the definitions are:
fperiod is a floating point representation of period so
fperiod=period * 1.0e-9
period = time - prev_call_time
tmax=max(time, prev_call_time, prev_prev_call_time,...)
Finally,
Can I access the intended period of a thread, that is the one that is
specified when creating it?.
Thank you,
Javier
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
