RE: New project...PCI based servo control board

["Craig Edwards" <cedwards-at-ceinetworks.com>]

More detailed comments.......the rest of my 2 cents for tonight.
-Craig Edwards


> Hi John,
>
> Sounds like we are thinking along the same lines...
> And yes, I'm certainly open to collaboration.

Great!

> At this stage, I'm envisioning a single PCI card,
> with an architecture that is very tightly coupled
> to the primary CPU. That's why I've mostly considered
> the PCI bus, despite the complexity and cost drawbacks.

> Most definitely FPGA based, because I'm sure we won't
> get it "right" the first time, at least with regard to feature set.

FPGA is the cheapest and smallest solution.  I'm
somewhat concerned about long term availability.
For this type of application, the design lifetime
could be many years.  I don't want to design around
a part that will go obsolete in a year or two.  I
think that can be avoided if we choose the right FPGA,
and the other advantages of FPGAs are too much to
pass up.

Agreed.  With regard to long term availability we need to make sure the FPGA
is built on a mainstream process that will be in high volume production for
a long time.  Also, I prefer a non-volatile architecture, i.e. one which
doesn't require a boot process during power up, but there is a cost
trade-off with regard to SRAM based FPGAs. 

> Actually, I guess I'm thinking that if we can get the
> initial board design completed with just a basic set
> of functions implemented, it could "grow" over time to support more 
> advanced features.

Good plan.

> Initially I was thinking of primarily including the functionality of 
> the Servo to Go ISA board, with stepper support being something for 
> the future.

I'm strongly in favor of providing pulse outputs from
the very beginning.  Using Geckos, pulses can drive
either servo or stepper motors.  And pulse outputs are
a purely digital, FPGA friendly solution, unlike D/A converters.  To meet
the full range of applications, we'll need both.

If I understand EMC correctly, the update rate for the
servo loop is 1KHz.  At that frequency, perhaps an all
digital (FPGA) system could make 20KHz or higher PWM
waveforms that are filtered to generate the analog
outputs. Then no D/A converters would be needed.  A
chunk of FPGA gates could be either a pulse generator
for steppers, or a PWM generator for analog output.
Only the output signal conditioning would need to
change.

I think the 1KHz update rate is pretty arbitrary, with a 1GHz main processor
and a PCI board I'd expect at least 10x better.  That's one of the things I
would like to understand in more detail...what are the bottlenecks to higher
update rates?  Seems most of the higher end motion control boards claim at
least a 20K update rate. Now providing that across 6 or 8 axis might be a
stretch...:)  PWM is also a good option, again the boards I've seen are
usually around 10 bits resolution (for the pulse width).  10 bit resolution
would require around a 20MHz clock (assuming a 20k update rate....if I did
the math right), so that should be easily done.  And 12 bit DACs are cheap
enough that I would include them as well.  My preference is to allow EMC to
close the servo loops internally, I think it's really one of it's strong
points.

> As you probably know, the PCI bus (and associated drivers) are fairly 
> complex, at least if one wants to do a full implementation.  Even 32 
> bit, 33MHz target only VHDL code for a FPGA instantiation is pretty 
> pricey, but I'm working on some options.

I know only enough about PCI to know that I can't possibly
do a PCI design on my own.  PnP and everything else are
way beyond me.

On the other hand, my strengths are in the area of the
control hardware - D/A converters, digital I/O, pulse generators, encoder
counters, etc., plus the interface between TTL or CMOS logic levels and the
real world. Noise, isolation, voltage swings, etc.  Digital inputs should be
isolated and I personally prefer to run 24V thru the switches instead of 5V.
Outputs need to be relays, either solid state or electro-mechanical.
Encoders need input buffers, power supplies, and filtering.  And so on....

Great...we need all "real world" experience you can offer!

> If we can afford a large enough FPGA, there will be plenty
> of room for stepper pulse generators and GP I/O.  As you pointed out, 
> there a large number of trade offs to be made with regard to how many 
> features we try to include on single board, but that's the fun of a 
> project like this.

> I think it's fair to say I'm pretty firmly in the "single board" camp, 
> as I really want a solution that is tightly coupled to the 
> motherboard. But having said that.. I guess we could consider 
> "daughter" cards....:)

The signal conditioning stuff will probably force a
two board solution.  Relays switching 120V don't belong
inside a PC, and there isn't enough space on the back of
a single PC slot for all the I/O wiring if everything is inside.  Maybe the
bus interface, FPGA, etc., should be on the PC card, with a cable (50 pin
ribbon or D-shell?) coming out of the PC to an interface card with opto-
isolators for digital input, relays or solid state relays for digital
output, and terminal blocks for the analog and pulse outputs and encoder
inputs?

Agreed...I never considered including things like spindle power relays on
the board.  By "single board" I was referring to concept of using one large
FPGA for all I/O, perhaps up to 8 axis, plus all the assorted GP I/O

The more I think about it, the more I think there are
really THREE parts to the project.  (Although they may
still wind up on only two boards.)

The central part is the basic control hardware.  This
is a mixture of D/A converters, counters, output registers
and input ports.  Except for the D/A converters, it's pure digital and would
fit in a decent FPGA, and even the converters are only a chip or two (or use
PWM and eliminate the converters).  It would definitely fit inside the PC.
With a largish FPGA, we could provide lots of inputs, outputs, counters, and
so on, at very low cost per channel.

Agreed...

On one side of the control hardware is the bus interface.
You are strongly in favor of PCI, for some very good
reasons.    There are also reasons to favor other
interfaces, and I think it would be really nice if the interface was
sufficiently divided from the actual control hardware that different
interfaces could be used.

Agreed...but I don't really want to introduce any trade offs to support
alternative bus interfaces at this stage..:)

Finally, on the other side of the control hardware is the interface to the
machine.  This doesn't belong inside the PC case, for a number of reasons.
It's also where a large part of the cost is hidden.  The cost to provide 8,
16, or even more TTL level digital inputs or outputs is very low. But
connecting those TTL signals to the outside world is more expensive.
Opto-isolators and the associated caps, resistors, and terminal blocks add
up quickly.  Using OPTO-22 type I/O blocks is easier, but even more
expensive. For outputs, the OPTO-22 blocks make more sense, but simple
electromechanical relay may still be cheaper if you can accept their
limitations.

Agreed...

I'd like to propose a two board system.  Board #1 contains
the bus interface and FPGA based hardware.  There could be
ISA and PCI versions that plug into a PC, and/or ethernet
or parallel port versions that mount outside the PC and
require external power supplies.  The common denominator
for all versions would be the connector to board #2.
Board #1 is a high tech board, with one or more fine
pitch FPGA chips, and possibly a fast, wide, complex
bus interface.  I would expect that people would want to
buy it already assembled.  Hopefully the price would be
under $200 for the PCI version, $150 for the ISA or
parallel port version, and maybe $200-250 for the ethernet version.  I'm
basing these prices on Jon's price for the universal stepper controller.
This board would have a bigger FPGA (which are getting cheaper as time goes
by), but would be smaller and not have the terminal blocks or I/O circuits.

The connector to the I/O board would be a 60 pin ribbon
cable or some other high pin count connection.  With 60
pins, board #1 could provide a mix similar to this:

power and ground - 2 or 3 ground pins, +5V, +12V, -12V
total 5-6 pins

6-8 axis outputs - 2 pins per output - either step and direction, or PWM
analog, determined by the FPGA program total 12-16 pins.

6-8 axis encoder inputs - 2 pins per input - either quadrature for real
encoders, or step/dir for open loop systems, determined by the FPGA program.
total 12-16 pins

24 digital I/O lines - 1 pin per line, input or output determined by FPGA
program total 24 pins


Hmm...this is a tough one... I definitely see the merits in a two board
architecture, but I'm still not crazy about requiring the use of a big fat
60 pin cable, carrying all those discrete signals.  Mostly it's the signal
integrity issues that concern me...but you may have more experience in this
area than I do.  For instance, it still seems to me that running shielded
diff cable for the position encoders directly to board #1 would more robust
(these signals can get into the tens of Mhz range).  I'd like to look around
at some other commercial systems and see how they handle these expansion /
fan-out kinds of issues.  No doubt a "breakout / interface" board of some
sort is needed, but I think the system partitioning is pretty critical.  

Board #2 is the interface board.  I see this as a low-tech design that
anyone could build.  The user would buy a bare board and stuff it to suit
their needs.  It would have space for the signal conditioning and terminal
blocks for all the functions on the 60 pin cable, but the user would build
it to suit their exact needs.  There might even be 2 versions of the PC
board - one limited to say 4 axis and 16 digital I/O, for a smaller, cheaper
bare board.  The other design would be for hexapod folks, with all 8
channels supported.  The bare board would probably cost $50-100, depending
on quantity.  The parts cost would depend on exactly how much I/O you need.

I REALLY like the idea that users can build their own interface
board...keeps the system "open" while still maintaining integrity of the
core. BRILLIANT!


Comments?  Suggestions?  Flames?

John Kasunich