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

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

Craig Edwards wrote:

Just a few more comments.... I think we are most in agreement...:)

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


This is actually pretty common now....maybe you pioneered more than you
thought..:)  But the way I'm currently thinking of implementing the PCI
bridge (in the same FPGA as the rest of the logic), you would need to store
the update code somewhere else on the board, then flash the FPGA. Or do
partial flashes (which a few FPGAs provide) Or provide another update path
like a JTAG port to USB, which I think is too much overhead.  I'll do what I
can here, but I think the cost penalty for providing in-system update
capability might not be worth it.   


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


Well... I was really referring to the software algorithms...but I think
Jon's on the right track on his next post..:)


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


Yep..specmanship it is....:)


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



Well, I think I agree....now that I understand your technique...:) I was
concerned about loop BW as well, but I think this might be good enough.
This part of the board may be a good candidate to simulate, as I think we
should insure that this solution can be used in applications that use the
STG board currently.  I agree that a 20kHz update rate is way more than most
small CNC machines require...and I'm not proposing to add much cost to
achieve it.  BUT a faster update has to broaden the range of
applications...and we are looking to improve on what is available
currently...:)



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



Oh I agree, speed per say is not the issue. Latency, probably....although it
may be swamped by the real time software interrupt responses, etc.



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

I agree...but what I was concerned about was bringing all these different
kinds of signals together into one cable..:).  Now, if the assumption is
that everything is converted to "standard" TTL or CMOS and then drive the
SCSI cable, that's better.  I suspect the only real tradeoff will be the
additional cost of a cable / breakout board / separate housing, but most
applications will no doubt make good use of it.  So I'm fine with using this
as our baseline approach for now...if anyone has other suggestions going
forward we can modify later.

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

AGREED...:)

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


One closing thought on board #2, I'd like to consider a SIMPLE bus expander
be included on it, the rational being that connectors / cables / FPGA pins
are costly and we don't want to burden simple machine applications with
functionality they won't use.... while at the same time there are
applications that could use a lot of discrete I/O.  I'm thinking something
like 4 address bits / plus an 8 bit data bus, separate I/O for simplicity
(total of 24 lines). For simple apps a default address could be used, giving
8 lines each way.  Each axis would have to use dedicated lines, as John
suggested previously, 4 lines per axis.  Ideally, I'd like to keep the total
at under 50 pins (not there yet...), so other ideas are certainly welcome.

Craig


John Kasunich