Re: EMC compatible computers

[jmkasunich-at-ra.rockwell.com]

Alex wrote:

> There is a possibility of another hardware model
> without a  high cost.
> Consider a controller which consists of several
> low-speed mother boards connected together either
> through the parallel data link or the ethernet.

Alex - when you say "low-speed motherboards", do you
mean x86, PC type motherboards?  If so, communication
from the Linux "high end" PC to the DOS "real time" PC
should  definitely be ethernet - the parallel port
offers no benefits in PC to PC communications.

> All the real time and close to the real time apps
> are handled by DOS (Free DOS). Front end is  handled
> by  Linux.

I don't see any real advantage between this and EMC as
it exists today.  Substitute "real time Linux task(s)"
for "DOS" and you have today's EMC, without the extra
cost of another PC.

> DOS can be serviced by a 386 single board PC.

True single board PCs are still quite expensive, because
they are special purpose, low quantity items.  Building
a 386 PC with mass market parts can be very cheap, but
gets bulky - case, power supply, disk drive, etc...

> Linux - some kind of a Pentium.

Same as EMC.

> Software cost - 0. Hardware - not very high.

You still have to write a real time program to run on
the DOS machine and generate the step pulses.  That is
a non-trivial task - you could start with the EMC code,
but you have to port it to a DOS environment.  And when
you are done, you have performance that will be no
better than EMC.

And the second PC still doesn't address the problem of
getting the step pulses out of the PC and to the motor
drivers.

A single fairly modern PC with RTLinux or RTAI is quite
capable of running the user interface, G-code interpreter,
and trajectory planner, and updating the outer servo loop
at 1KHz or better.  Only multi-Khz step generation is a
real burden.  A handfull of dedicated logic chips or a
single FPGA can do that far better, and cheaper, than
even the fastest Pentium.

I think the real question we are debating is how does the
PC running the outer servo loop talk to the chips or FPGA
generating the step pulses?

<begin philosophical digression>

It's kind of interesting, how things have progressed.  In
the bad old days, computers weren't fast enough to run
CNC machines, so there were dedicated controllers.  They
were maintainence nightmares, completely closed systems,
with extremely expensive replacement parts.

Then came the good days - open source software, running
on commodity PCs, sending step and direction signals out
the simple parallel port to readily available, simple
drivers like Geckos.

Now, with the threatened extinction of parallel ports,
it seems we're about to move back to the bad old days,
putting intelligence and complexity in external black
boxes because we no longer have a _simple_ way to get
information in and out of the PC.  To put it bluntly,
this _sucks_!

The real question that seems to be facing the PC based
CNC world is how do we do simple, bitbanging I/O out of
what is becoming an increasingly closed PC environment.

The original ISA bus was open, simple and slow.  Anyone
with a little digital knowledge, a soldering iron, and
a decent cookbook could design an ISA board.  Then PCI
came along.  The PCI bus is "open" only to those who
plan to manufacture boards in quantity.  It requires
a bus interface ASIC, which is targeted at high volume
production.  The ASIC comes in a zillion-pinned surface
mount package that few mortals can hand solder, has an
inch-thick databook, and will be unavailable in a year,
replaced by the next generation.  PCI also runs at 33Mhz,
making board layout and signal routing much more critical.
It's great for video cards, network cards, and anything
else requiring bleeding edge performance.  But for the
guy who needs 8 to 100 or so bits of simple digital
I/O, it's a nightmare.

We were saved from the loss of ISA by the printer port,
which has a hardware interface that is simple enough
to still be "open" to the experimenter & hobbyist.
Now that is going too...

There has got to be a better way - and USB, ethernet,
firewire, or anything that requires another cpu to pack
and unpack data ain't it!

<end philosophical digression>

John Kasunich