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

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

Marc/list,

I apologize if I get a little wordy in response to some of your points, but
I think you raised some great issues that no doubt deserve some additional
discussion.  There are different but valid approaches to small machine
control, and I think it's helpful understand the rational behind the
different approaches. I'm the first to admit there are no right or wrong
answers in this kind of debate, but I would like to really understand
other's opinion here.

Craig Edwards




>Well, What I don't understand is constant push to put these boards inside
the PC.

This is really an software architecture issue... in my case I'm interested
in supporting/extending the EMC/ RT Linux concept of tightly coupling the
processing CPU with multi-axis servo motors/encoders.  Using one "central"
CPU to close multiple servo loops seems like it would have real advantages
in small machine control, but admittedly this is an area that I would like
to understand better.  For many folks, that are using steppers in open loop
mode, this is a non-issue.  In my case, I want to develop a high performance
servo system, using EMC to close the 4 (or more) axis of motion
simultaneously.  If you distribute the processing elements that close the
individual axis's, it becomes more difficult for the central processor to
"compensate" for the varying degrees of servo following error.  Consider
applications like helical interpolation, where you really want tight control
of three axis's position simultaneously in real time.   Certainly, this can
be done in a distributed system, it's just my opinion that it's simpler /
lower cost / and higher performance to do so using a tightly coupled
architecture.  Comments pleease....:)


>People Mention "Speed", Speed is relative. 
>Honestly What do you need with 32, 64, 128 megabyte per second data rates?

Agreed, BW is not the issue.  This is only an issue as it relates to latency
(think of it this way... how long before the motor servo sees a command to
set current, and then how long before the 'CPU' receives information
regarding the actual position of the tool...and then how long before it
outputs a new corrected value for the current...etc, etc).   And of course,
this only applies if you are implementing a closed loop system in the first
place.

>The way I see it sticking high voltage, high current interfaces inside the
PC is Toast or at the very least EMI if not EMP ;-) Waiting to happen.


AGREED... Standard PCs don't make for very good enclosures for machine /
motion control.  One nice thing about PCI (or ISA...) is that it's available
in a wide variety of formats.  John K. and Jon both have great packaging
approaches to addressing this, others are using PC104.  But with regard to
the machine interface, I agree that some sort of breakout / interface board
is needed for most all real world applications.  Trying to push the low
level machine interface into a standard office type PC does not make sense.



>PCI is a pain to use (Relative to many other possible options).

Well, if you are starting from scratch as a hobbyist I agree.  But once you
have a lot of experience with PCI (including software drivers), it's really
not that bad.  Works pretty well, and is actually quite robust, even in
applications like avionics, telecom, or even... machine control.
Hopefully... If I can pull this project together, you would be pretty well
insulated from the "complexities" of PCI. If you choose to use the board in
a system running EMC / Linux, it would be supported as a PnP device,  at
least that's my goal.

>Any and all possible physical interfaces are a crap shoot on which NEW type
will take over and/or which OLD type will be pulled from the next Microsoft
>hardware push.


No doubt this is true for the long term.... But personally, I'm very
confident that PCI-X will be around for the next 3-5 years.


>The obvious solution to sticking the driving electronics in the PC is to
have external modules. Since everyone does this anyway. Why push the
"Controller"
>into the PC. Put it close in a physical and electronic sense to the driving
electronics.

Basically, I agree with putting the control close to the driving
electronics.... it's just that I'm thinking of the PC as a "processing
element" that's part of the machine controller. 

>All we need to do is define or copy a standard interface protocol. Make it
data based not physical connection based and stick to it. make all rewrites
or new >software/hardware interfaces follow the spec.



Agreed 100%, it would be really nice to have a set of lower level software
APIs defined that would allow for various types of low level hardware
interfaces to be supported. I know there are various industry initiatives in
this area, but I've just not had the time to research thoroughly.  I'm
looking forward to meeting some folks at NAMES who might have more knowledge
as to what might make sense here.



>This makes the physical interfaces much more flexible and much easier to
isolate. Serial protocols are simple and easy to isolate using fiber optics.
I'm not >talking leading edge here either, we should easily be able to top a
megabyte per sec with simple stereo cables or fishing line. RS-485 drivers
are dirt cheap >and good in noisy env. Firewire screams. USB is in
EVERYTHING and embedded controllers are cheap and easy to find. 
>The EPP port would be a good place to start, but only for DATA, not bit
banging transistors.

>A simple uController connected to the parallel port could manage a sync
serial connection between the PC and "Box". The Box could easily have a
watchdog type >setup to hit an ESTOP if the connection fails for some
reason.

>I just seems like we are heading in the direction of "Win-Modems" or
"Win-Printers" Those stupid (and Dumb) devices that only work because the PC
CPU is
>directly managing very time sensitive operations and spending WAY too much
system time doing it to run a device the HAD a very well defined interface
used for >many years. What we got were devices tied so closely to a specific
version of a specific OS they were useless anyplace else and for little or
no advantage.

>Far and away the most problems I've seen mention of relate to bit banging
stepper motor drivers and 10-20-30Khz and Jitter or speed issues and RTOS
Issues.
>Unless I'm missing something the only reason we Need the RTOS is to allow
the Bit Banging.

>The Problem is not that your 5 Ghz Titanium II PC CPU is too slow, it's all
the other crap it has to manage and get back to toggle your bits at exactly
the >>
>right time.

>A $3.00 dedicated uController will do a MUCH better job.

>Offload 20,000 bit banging stepper pulses per second is a good start but
moving up one level and splitting the work at the spline level would save a
ton of
>timing critical problems and make everyones life easier.


I agree that a "desktop PC" does not make a very good machine controller per
say, especially if your definition of "PC" includes using it to run MS
office or even a CAD application.  But I think that many of us use the word
"PC" in more of an embedded control sense, where we take an obsolete PC and
install only EMC on it, OR take John K's approach and use a cheap single
board computer (could be just a motherboard...) and use it as a core
processor for a dedicated controller. This approach allows functions like
networking and human interface options (touch screens, pennants, displays,
keyboards, joysticks... Etc) to be "borrowed" from the PC universe and
applied to standalone machine control. With the right real time software
package, a 1 GHz motherboard makes a pretty good bit banger for under $100
(OK, under $200, if you include memory and a hard drive), especially if can
make use of the processing resources to provide a really nice GUI, user
friendly servo tuning diags, DRO functions, etc, etc, etc.     You can just
separate the pieces back out..... But that goes right back to the first
issue regarding the servo control...:)  From my perspective, there is room
for both packaging approaches, I really don't think either is "wrong".

  
>We just need a standard interface at that level IMHO.


Marc.