Re: Low cost Servo Controller

----- Original Message -----
From: Bertho Boman <boman@...>
To: <CAD_CAM_EDM_DRO@onelist.com>
Sent: Sunday, September 19, 1999 4:27 AM
Subject: Re: [CAD_CAM_EDM_DRO]Low cost Servo Controller


> From: Bertho Boman <boman@...>
>
> I am happy to see that you are going the digital way for the servo amp.
Please keep us informed on your progress and thoughts.
>
> You mentioned about using start-end positions and calculating speed for
velocity feedback. I do not think that will work
> because you need continuos and "instantaneous" velocity feedback. If
there is a delay in the velocity feedback signal the servo
> loops will be all messed up.
>
> The software tachs go to great lengths to QUICKLY calculate the velocity
from the time between two encoder pulses. There has
> been a lot of research on how to do that fast enough that the introduced
delay is not significant to the servo loop.
> Preferable, the delay should also be independent of the value converted.
There was an article in one of the IEEE magazines some
> years ago about the theory and software. With all this discussion, it is
only a question of time before I have to dig it
> out. Today's DSP should fly through the time to velocity calculations.
>
> I did such a calculation 22 years ago on a MC6800 for a EKG & pacemaker
tester. It had to display both Beat per Minute and time
> in ms between pulses. Since the software also was used for timing, the
math loops duration had to be independent of value or
> the timing would have been messed up. I did it all in hand assembly! (No
PCs at that time.... only 4 & 8 bit Intel's and
> Motorola's 8-bit 6800 available) It makes me feel old thinking back that
far.
>
> Bertho

Yes, that was my (perhaps unclear) point about the unsuitability of the
629's for high precision work. In my table-top prototype, I am running A &
B of each encoder through an XOR gate, then using PWM capture to measure the
width of each pulse to generate high-speed velocity feedback. This number
is used in the innermost feedback loop (with current goal velocity) to
generate the PWM pulse width (effectively motor current). There is a second
set of encoders (rotary on a cable for the prototype, linear for the final
hardware) for position feedback. The system 'learns' the characteristics of
the ball screw (threaded rod in this case) for periodic and cumulative
errors, the it fudges the velocity goals to yield true linear velocities
instead of rotational ones.

Backlash is still a big problem, the system can deal with backlash on
direction changes, but when you are moving a rotary cutter, the cutting
action can create a force on the head at an angle to the feed vector. This
means that if I change directions on the minor feed axis, I never know which
side of the backlash the nut is loaded to (because I do not know if I am
actually removing material or not). At this point, I am experimenting with
current measurement on the spindle motor and taking into account the
clockwise rotation of the tool. The problem with this approach is that I do
not know if I am cutting with the full face of the cutter, or just one edge.
I suspect that current measurement will not be effective, next try is strain
gauges on both axes. I concern with strain gauges is the vibration levels
when cutting with a 5hp router (wood).

Does anyone know how low the actual backlash is on "zero backlash" ball nuts
under load? Since they cannot be infinitely stiff, I assume that it is
non-zero. Fortunately, about 1/200th of an inch is acceptable accuracy for
most of what i plan to use the system for, sanding can erase a few sins.

Dean