Re: digital servo controller to offload the Parallel Port?

[jmkasunich-at-ra.rockwell.com]

>> I'm not crazy about Jon's divide-by-n step frequency
>> generator, I'd rather see a direct-digital-synthesis
>> one like the one Mariss (Gecko) is developing for his
>> G2002 system.
>
> What's wrong with it?.

I'm not saying there is anything wrong with it, In fact,
if my desire to make (steel) chips overpowers my desire
to play with (silicon) chips, I might well end up using
your board on my CNC Shoptask conversion.

I just like DDS better.

> It allows you to set the time between pulses with
> 100 nS resolution

1/5000nS = 200,000 steps/sec
1/5100nS = 196,068 steps/sec (and a fraction)
1/5200nS = 192,307 and a fraction
and so on

In your system the loop is closed, either by counting
the output pulses or with an encoder.  Those fractions
get corrected by the outer loop and it works fine.  If
you were running open loop, it would become a mess
quickly.  DDS gives precisely known and evenly spaced
output frequencies, and if implemented carefully can
run open loop without an encoder OR counting the output
pulses  (actually, the accumulator value IS the position,
with extremely fine resolution).

Also, the even spacing of available output frequencies
means you may only need a 16 bit DDS adder, rather than
a 24 bit divider.

> Unless you actually need step pulses above 100 KHz, I
> believe this is the most compact way to do it in an FPGA.
> The DDS scheme almost HAS to take up more gates on
> an FPGA, unless you multiplex the hardware between
> channels.  I went with a totally dedicated hardware
> per channel because there was less chance of my screwing
> up some subtle interaction between channels (axes) that
> way.  The CPU can EASILY figure out the precise counter
> value to use to get the precise timing desired.  One
> divide on a Pentium is no big deal.

I agree that a 24 bit divide-by-N is takes fewer gates than
a 24 bit accumulator.  But a 16 bit accumulator (perhaps
followed by a fixed post-scaler divider) takes less than
a 24 bit divide-by-N and a 24 bit encoder counter.

Actually, you could have use a 16-bit or even 8-bit counter.
If EMC reads the counter every 1mS, then an 8-bit counter
could handle up to 128KHz, with EMC maintaining the higher
bits.  Different strokes for different folks - you chose
to keep the entire count in hardware, which might be more
reliable.

> One refinement I use in this scheme is to have a counter
> start at zero at the beginning of the interval, and then
> use a magnitude comparator to end the interval when the
> counter equals or exceeds the limit value form the CPU.
> This way, a long interval does not have to expire before
> the pulse generator can respond to a sudden request to
> increase speed.  Conversely, one step pulse may still
> come out at the high rate when a sudden change to a low
> speed is requested.

None of that is needed when using a DDS - the accumulator
value is the desired position, with extremely high resolution
and updated at 1MHz or higher.  When it overflows a step
pulse is generated... period.  With low commanded speeds,
it may take many milliseconds before a pulse comes out,
but the position is still the integral of all the commanded
velocities that were updated every mS.

> The DDS scheme may give a more balanced response time
> to velocity changes, but it replaces a magnitude
> comparator with an adder and yet one more 24-bit register.
> That HAS to eat FPGA resources.  I'm pretty much filling
> a 30,000 gate Xilinx XCS30 FPGA with 4 24-bit encoder
> counters (small), 4 24-bit rate generators (dominates
> the chip!) and bus interface and digital I/O (tiny).

DDS requires a command register (same as divide-by-N), and
a current value register (same as divide-by-N).  It requires
an adder, where your divide-by-N requires a magnitude
comparator.  I don't know the relative complexities of
those two items, but I bet they aren't far apart.  My
previous experience with DDS was using the Xilinx 4000
series.  The CLBs in that part had fast carry connections
from one CLB to the next, designed specifically to build
adders.  You can build a adder as long as a column of CLB's
is high, with high performance and low gate count.  I don't
know enough about the newer FPGAs to know if that's still
true.  I don't remember whether we got 1 bit per CLB or 2
bits per CLB, but we had several 20+ bit DDS generators
in a 4006, plus a A/D control subsystem, precision dead
time generation (the biggest chunk) and a bunch of glue
logic.  I don't remember the equivalent gate count of a
4006, but I doubt it was 30,000 gates (this was around
1993).

>> The G2002 currently includes a microprocessor, which
>> I don't like because it has it's own software to be
>> written and maintained.
>
> Yeah, you bet!  I MUCH prefer an FPGA.  Much more predictable.

>> I'd like to see a version of the G2002, without a micro,
>> where EMC can write directly to the Gecko step pulse
>> generators using the parallel port.  Advantages are
>> good splitting of work between hardware and EMC software
>> (like PPMC), a nicer step generator, (DDS instead of
>> divide-by-n), and the low cost that comes from Gecko
>> because of their automated SMT assembly and test.
>> (Sorry Jon, but you can't compete with Mariss's
>> chip-shooter when it comes to cost...although your
>> FPGA based design might offset that compared to his
>> MSI design.)
>
>
> Well, maybe I should look into the costs/fitting of a DDS, just
> to satisfy you!  It might fit, especially if I multiplex the DDS
> to share one set of resources for 4 axes.  That would probably
> reduce the timing resolution to 500 nS or something.

Don't do it for me.  I'm the kind who will want to roll his own
anyway.  I sometimes suffer from NIH syndrome (Not Invented
Here).

> But, I really DON'T see the problem here.  This is WORKING
> hardware/software - ready to plug in and go, with the
> software already on the CD.

You got that right!  At this point, what I am proposing is
nothing but hot air (OK, hot electrons bouncing off the
inside of a CRT.)

I'm gonna keep discussing it on the G2002 forum.  If I can't
push the G2002 in a direction that is EMC friendly, I'll
either use your card, or invent a DDS based one.  There is
room for multiple ways of connecting EMC to motors.

John Kasunich