Re: [CAD_CAM_EDM_DRO] Encoder counts/revolution

Hi Pete,

Good points. Fixes are to use integer control variables for loops, or
compare float variables with thresholds of error:

if(fabs(StartAngle - EndAngle) < fabs(step))
{
}

One should also increment by an index, rather then by an accumulation.

ArcAngle = step * (double)Uindex; /* increment the angle to next cord
*/

This way errors won't accumulate.

However I'd rather ask for leadscrew pitch, stepper steps/rot, gear
ratio, etc. in floating point numbers and calculate the axis resolution
for the user, rather then have him/her loose precision when the axis
resolution is other then integral (like my nice 8000). This will often
happen if imperial and metric drive parts are mixed. It can even happen
with "all inch" parts. I have a Dayton gear box in a stepper RDF (radio
direction finding) application, and the gear box has a 24.1 : 1 ratio!

Now what I'm having fun with is the calculations needed to calculate
moves around arcs. Getting the start angle, and end angles that "wrap"
around 0 degrees is a problem! Even the quadrant boundaries cause
problems in calculations! Anytime something "chases it's tail" as in
moves around arcs, or circular buffers where a fixed "depth" exists
cause similar problems, as I've recently found out!

Alan KM6VV


Peter Harrison wrote:

>
> In article <3D09883E.E2F1C0E7@...>, Jon Elson <elson@pico-
> systems.com> writes
> >Assuming your resolution is high enough, any program that uses
> >floating point arithmetic (EMC, for instance) will handle this perfectly.
> >Some other progams that do all the arithmetic in fixed point may have
> >some odd errors that creep in at certain positions where the
> >roundoff accumulates just before it is corrected. I suspect that
>
> Not to be too picky but...
>
> If the software has bee written appropriately, you will not have
> problems. However, if home-brewing you need to watch your step a bit
> (poor pun but free).
>
> Use whatever floating point your programming language has and try the
> following pseudocode.
>
> a := 0
> repeat
> a := a + 0.1
> until a == 10.0
>
> Be prepared for an unpleasant surprise in most cases. the decimal value
> 0.1 is a recurring fraction in binary and cannot be represented exactly.
> Thus tiny rounding errors will accumulate with a calculation like the
> one above. There are many ways to avoid the problem but your should be
> aware of it.
>
> This has no direct bearing on the original question about encoder counts
> but, if you are working in a conventional decimal system with sensible
> leadscrews like 8TPI or 4mm or whatever, then why make the sums more
> difficult than they need to be.
>
> pete