RE: digital servo controller to offload the Parallel Port?

["j.guenther" <vze2z45u-at-verizon.net>]

It seems to me that EMC could be made G2002 friendly just as easy as any
other control program can be made G2002 friendly.  I have two projects in
mind for the G2002 and one of them is EMC working with it.  It seems to me
that the servo controls in EMC could be made to deal with the G2002 or
something a g2002mod.o function written to control the G2002 in much the
same manor that EMC controls the stg cards.

John Guenther
'Ye Olde Pen Maker'
Sterling, Virginia

> -----Original Message-----
> From: emc-at-nist.gov [emc-at-nist.gov]On Behalf Of
> jmkasunich-at-ra.rockwell.com
> Sent: Thursday, December 19, 2002 15:52 PM
> To: Multiple recipients of list
> Subject: Re: digital servo controller to offload the Parallel Port?
>
>
>
>
>
>
> >> 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
>
>
>
>
>