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

[jmkasunich-at-ra.rockwell.com]

Craig Edwards wrote:

> More detailed comments.......the rest of my 2 cents for tonight.


>> FPGA is the cheapest and smallest solution.
>> I'm somewhat concerned about long term availability.

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

Jon Elson made an interesting comment about small quantities
of parts being available long after the part is "obsolete".
John Sheahan mentioned VHDL or verilog as an upgrade path.
Both good points.  I first used FPGAs in 1991 (Xilinx 3000
series) and most recently in 1997 or so (4000 series).  I
used schematic based design methods, and have no experience
or tools for VHDL/verilog.  I think I'll have to leave the
FPGA choice to folks who are more current than me.

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

Alot depends on how the boards are built.  If I have to
assemble the board, I'd rather use a RAM based FPGA, and
socket the little 8 pin config PROM.  If it was being built
commercially, non-volatile FPGAs could be programmed before
soldering, or on board.

Actually, the project I did in '91 stored the FPGA code in
the CPU's memory space, and the CPU controlled the loading
of the FPGA.  In a PC environment, it might be possible to
store the FPGA program on disk, and completely eliminate
programming of PROMs or FPGAs during board construction.
Maybe a little far-fetched, but it would be cool to be
able to download a new FPGA configuration and install it
without even opening the PC case.

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

Yes, Jon has confirmed that 1KHz isn't a magic number.  Pulse
generating hardware, encoder counters, etc, don't really care
what the servo update rate is, so we could continue to allow
that to be determined by the ini file.  It would be good to
have a target rate in mind though.

> That's one of the things I would like to understand in
> more detail...what are the bottlenecks to higher update
> rates?

Only one bottleneck - Money.  Money for faster PC CPUs, and
faster, more sophisticated control hardware.

OK, that was the smart-aleck answer.  I think for many folks
the bottleneck that drives them from pure software (step/dir
out the parallel port) to a hardware solution, is stepper
pulse rates, not the servo update rate.

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

I think Jon Elson has reported that he gets good results at
1KHz servo updates.  Maybe 2KHz or 4KHz is better, but is
20KHz really good for anything except specsmanship?  I'm
talking about machine tool control here, not pick-n-place
machines or other high end motion control.

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

Actually when I said PWM yesterday I was over-simplifying.
You are right that you would need a 20MHz clock for 20KHz
PWM with 10 bit resolution.  But you would need an analog
filter with 1KHz or less bandwidth to smooth that 20KHz
PWM waveform to a clean analog signal.  Not so good.

What I actually had in mind is PFM (Pulse Freqency Modulation).
I can't explain well in words, perhaps a comparison would be
more clear.  For simplicity, I'll limit it to 3 bits resolution.

For an output of '0':

PWM - 00000000000000000000000000000000
PFM - 00000000000000000000000000000000

For an output of '1':

PWM - 10000000100000001000000010000000
PFM - 10000000100000001000000010000000

so far, no difference.  Now for an output of '2':

PWM - 11000000110000001100000011000000
PFM - 10001000100010001000100010001000

For an output of '3':

PWM - 11100000111000001110000011100000
PFM - 10010010100100101001001010010010

For an output of '4':

PWM - 11110000111100001111000011110000
PFM - 10101010101010101010101010101010

and so on.  The PFM waveform is _much_ easier to filter
to a smooth analog signal, or to put it another way,
the filter bandwidth can be much higher for the same
amount of analog ripple.  The difference is clear even
at 3 bits resolution, but it is simply enormous when
you get to higher resolution.

What's really cool is the the PFM signal can be generated
by the same hardware circuitry that generates step and
direction pulse trains.

The drawing at:
http://home.att.net/~jekasunich/CNC_Output.gif
shows the circuit I have been planning to use for my
pulse generator, modified to include the PFM output
signal and the analog filter.

You can trade off analog resolution for update rate by
changing the time constant of the filter.  The basic
PFM signal has 16 bits of resolution.  If you filter
the snot out of it, you can get nearly that much analog
resolution, but with low bandwidth.  If you reduce the
time constant of the filter, the ripple goes up, which
reduces the effective resolution.  But as the resolution
drops, the bandwidth improves because the filter is faster.

> And 12 bit DACs are cheap enough that I would include
> them as well.

I wouldn't.  I think PFM signals are more versatile that
DAC's.  I'd rather spend the money on a better FPGA, or
not spend it at all.

> My preference is to allow EMC to close the servo loops
> internally, I think it's really one of it's strong points.

I agree 100%  There are three ways to run the system, and
all three look the same to EMC.

1)  Analog output to servo amps, feedback from real encoders
    through encoder counters.

2)  Step/Dir output to servo or stepper drives, feedback from
    real encoders through encoder counters.  Lost steps in
    the drives don't matter.

3)  Step/Dir output to servo or stepper drives.  If servo,
    encoders feed back to the drives (Gecko style).  The
    step and direction pulses are counted by the 'encoder'
    counters and serve as the feedback for EMC's servo loop.
    EMC does not see the 'real' encoders, and with steppers,
    no real encoders are needed.  This is open loop to the
    motors, but EMC still has a closed servo loop internally.

Jon Elson gets the credit for #2 & #3, his stepper controller
does exactly that, and I shamelessly copy good ideas when I
see them.  #1 is classic analog servo.

>> The signal conditioning stuff will probably force a
>> two board solution.

> 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

Understood.  I think it's important not to lose sight of
the breakout board - as VLSI gets cheaper, the overall
cost is driven more and more by the interface to the
outside world.

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

> Agreed...

>> On one side of the control hardware is the bus interface.
>> 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..:)

Bus interface performance isn't that inportant.  Even with a
20KHz update rate and 8 axis, the data rate is fairly low.

Outputs - 8 axis x 1 16-bit command value per axis = 16 bytes out
Inputs  - 8 axis x 1 16-bit encoder count per axis = 16 bytes in
GP I/O  - 16 inputs and 16 outputs                 = 2 bytes each way

Total is 18 bytes each way, times 20KHz is 720,000 bytes per second.

With a more reasonable 4KHz update rate and 6 axis in use, the
total is 112,000 bytes per second.

Any parallel interface (PCI, ISA, parallel port) can easily handle
these data rates.  Serial interfaces such as ethernet, USB, and so
on can also handle the data rates, although latency may be an issue,
especially at 20KHz.

>> Finally, on the other side of the control hardware is the
>> interface to the machine.

> Agreed...


>> I'd like to propose a two board system.
>> Board #1 contains the bus interface and FPGA based hardware.

>> The connector to the I/O board would be a 60 pin ribbon
>> cable or some other high pin count connection.

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

They have to become discrete signals eventually.  Ultimately
you will have 60 (or more) individual wires, coming from limit
switches, encoders, motor drives, etc., scattered all over the
machine.  Some will be two conductor shielded twisted pairs,
some will be 4 or 6 conductors, some will be individual wires.
All of them have to be screwed into terminal blocks somewhere.

> Mostly it's the signal integrity issues that concern me...
> but you may have more experience in this area than I do.

I think the integrity would be better if the I/O board
has all the signal conditioning and the signals going
to board #1 are all TTL (or 3.3V CMOS, or whatever...)

Just to make it clear - I don't want to run the 60 pin cable
a long distance.  The SCSI-3 cables I mentioned yesterday
are a perfect example - long enough to keep the nasty stuff
away from the FPGA, but no longer.  If you want the PC to
be 20 feet from the machine, then either run the individual
signals (limit switches, encoders, etc) to the interface
board through individually shielded cables, or move the
FPGA and interface boards to the machine using ethernet.
The interface board and the FPGA board should always be
close together.

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

The encoder can be 5V or 12V, single ended or differential,
open collector or totem pole.  The interface board should
handle that stuff - you would build the board according to
the type of encoder you have.  By the time the signals leave
the interface board for the FPGA board, they are standard
digital signals, ready to go right into the FPGA pins.

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

Unfortunately my experience is with VFDs, not CNC.  But
many of the same issues apply.  Our most recent drive has
4 analog outputs, 4 analog inputs, 12 digital inputs, 10
digital outputs, and an encoder input.  The board that has
all the I/O conditioning and terminal blocks is nearly
twice as big as the board with the brains on it.  The brain
board and the interface board are 1 inch apart, and the
interface is a pair of 36 pin board to board connectors.

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

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

Thank you.  That's what leads to the 60 pin low-tech
interface.  I'd like the interface board to be simple
enough that it could be built with DIPs in wire-wrap
sockets and axial leaded passives, or with SOIC logic
chips and 0805 passives, or anything in between, based
on the needs of the individual users.  If it uses 74HC
logic chips, standard op-amps, and simple passives, it
will be obsolescence proof and very flexible.  Meanwhile
the high tech stuff is captured on the FPGA board, where
the average user won't have to deal with it.

John Kasunich