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

["D.F.S." <dfs-at-xmission.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....:)

To save Space I'll just post general responses...

I Agree a "Central CPU" is important.

I think a tight closed loop is important.

I think the logic to close the loop needs to be LOCAL to the controller.
This is behind my contention a DEDICATED CPU doing that and nothing else.

A Five dollar uController spinning thru a loop of 200 lines of code and NOTHING
else can be VERY deterministic.

You can be absolutely assured you will check that 'Bit' and make an adj. 50,000 Times
Per second EACH AND EVERY Second.

"All the other Crap" running on the PC I mentioned is not CAD MS-Word and Internet
Exploder.  For the task at hand, Memory Refreshes, Hardware Int's, and Touch screen updates
Managed by the OS Kernel and Drivers ARE Crap as far as My Servo Loop is concerned.

I want that Bit/Speed/Analog Value, checked and remedial action taken every 20 uSec EXACTLY and Without Fail,
I don't Care about the packet storm on the Ethernet port, The fact we were in the middle 
of a Ram Refresh or a quick or slow block of code due to disk swaping, Kernel Processes or 
Memory Cache or CPU Pipeline Effects.

At its most basic level We need to Move Axis X,Y,Z A,B,C From Wherever they are Right Now
To a New Position .00? Seconds From Right Now. ESTOPping on predefined Conditions.

Que enough of them up to avoid "Buffer Under-Runs" and Tightly Couple the process to the 
Hardware and you are done.

Am I oversimplifying This?

If Not The Logic to close that loop is fairly basic and easily burned to a dedicated uController.
Make the System Accept integer "Physical Machine Units" Like Steps, Millionths or an inch, 1/400ths
of a turn on an optical encoder, Whatever and Make EMC handle the conversion at a higher level.

No floating point math or major calculations required...

By the Same token It would be Stupid to try and move the user interfaces, EMC Code or other  complex code
to the uController. Leave it on the PC where we have tons of tools, development libraries and infrastructure
to support it. 

Segment the Simple but tedious and very time critical operations and let that little simple programmed device
spin its wheels at 20 Mhz, doing nothing but 6 tasks a million times a second...

Granted it won't Run at 300,000 Hz but I can't even imagine needing 1/10th That.

Marc