Re: 20 Amp 80 V $99 DC Servodrive

Jon, thank you for the kind words. Actually there is no proccesor
involved, just a pair of 4-bit adders and 4 4-bit U/D counters for
that section. The sum output is indeed a 2s-compliment weighed 8-bit
value.

Regards to how many bits resolution is enough for following error,
the snap answer would be "no amount is enough". My view is following
error is a dynamic phenomena in response to inertial loads and is
meant to be taken out within a few mechanical time-constants of the
motor.

Your point intrigued me so I set up a test to measure following error
on the test motor I am presently using. The motor is a NEMA 23
rated at 25 Amps stall (300 in-oz) and 28VDC. I commanded it to turn
1,000 RPM with no ramping. For a max following error of 100 counts,
the motor accelerated from zero to 1,000 RPM in 0.0032 sec. and
caught up to the now moving command position in an additional 0.0035
sec. This I think is considerably better than what a step motor could
do.

I can see your point though if very large load inertias are present
and the mechanical time constant is very long; then 12 or 16 bits of
resolution may be needed. However this drive is supposed to be an
inexpensive alternative to step motors while offering some
improvement in performance. Consequently some comprimises are
necessary while still meeting the requirements of the majority of
step motor applications.

Mariss

> It sounds like this system only keeps an 8-bit signed difference,

and so

> it
> will lose position in blocks of 128 encoder counts, is what you are
> saying,
> here. I know the small processors have a lot of housekeeping to do
> without
> adequate hardware assist, but I think a 128 count difference could

lead

> to
> a loss of position during bind-ups, crashes and emergency stops.

This

> could
> lose the great advantages of closed-loop operation.
>
> If the NC computer was ALSO reading the encoder, then this would

cause

> some
> very odd transients, when the positioning loop tried to correct for

a

> loss of
> 128 counts in the velocity loop, but at least the displayed position
> would not
> be premanently offset.