Re: digital servo controller to offload the Parallel Port?

[Jon Elson <elson-at-pico-systems.com>]

jmkasunich-at-ra.rockwell.com wrote:

>
>
>John Guenther wrote:
>
>  
>
>>What Les said is true but it would be really nice to have a
>>lower cost solution to servo control with EMC than the STG card.
>>Before you all flame me, I know that you can use Gecko 320 / 340
>>drivers and the there is PPMC from Jon Elson and maybe some other
>>solutions.  IMHO for home shop use the STG cards are really cost
>>prohibitive, at least in my shop.
>>    
>>
>
>IMHO, Jon's PPMC is the right direction as far as the interface to
>the PC is concerned.  The EPP port gives fairly fast and simple
>access to external hardware.  The hardware offloads the time critical
>task of generating step pulses, and EMC handles the servo loop.
>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?  It allows you to set the time between pulses with 
100 nS resolution.
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.

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.
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).

>  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.  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.

Jon