Re: [CAD_CAM_EDM_DRO] Interface options, headless boxen, and remote control ...

Larry Edington wrote:

> RS-422 / 485 is still a serial device. There's just so much you
> can do with a serial data stream with a UART or USRT that is
> decoded in the PC's I/O space when reading and writing to a
> device at the end of the pipe. I've designed motor controllers
> using RS-485 links with microcontrollers and they work great.
> But it's not a good design for a CNC control.

Which is where my ignorance comes into play. I should get a little
more familar with the actual application before I comment any more
then. Thanx for the insight.

> I don't care at all for the parallel port either.
> t's greatly limited and is a kludge for CNC due to the way
> it was designed for parallel printers back in the early 80's.

Yes, but the IEEE 1284 standard does open up quite a bit of
capability IMHO. But it _is_ losing favor to USB, I'll admit. I
just don't like the idea of USB as a "standard" because it is not,
its a simplistic, open-ended bus.

> A few years ago I designed an ISA card that provided a several
> 8 bit ports and used a 37 pin connector like the Ahha card does.
> It used a simple PLD for address decoding. That was good for
> several axis of I/O but still was limited by the 37 pin connector.
> So I added another 25 pin internal ribbon cable connector and
> added a 25 pin slot mounted connector. It was still limited by
> the fact it was just a dumb I/O port. All the load is on
> the OS and host processor.

Which is why I like the IEEE 1284 approach because you can do
memory-mapped I/O and direct memory addressing (DMA), in addition to
regular programmed I/O (PIO). Again, I need to find out if some of
the PCI parallel port cards out there have Linux drivers (I haven't
researched this enough yet).

The _other_option_ is to use digital I/O with a massive number of
relays or other isolated I/O -- from as few as 16 channels to as
many as 96. I have never done this and don't know what kinds of
programming issues would arise, but the cards _are_ low-cost and
many have Linux drivers (check out Sea Level Systems,
http://www.sealevel.com). Again, I'm kinda ignorant on the actual
end-device interconnect and data stream (I will change this soon).
But I assume you could control upto 6-axis with a 48-channel card
(again, total ignorance here)?

Maybe the "ideal" combination is to use DIO for individual
axis/device control and interrupts and IEEE 1284 for high-speed data
transfers? Ack, I really need to read up on this more before I talk
anymore.

> I've been looking at this for a few years. ISA was the way to go.
> But those days are gone. ISA is a dead bus and is going away.
> Welcome to the world of PCI. There are PCI parallel multiport
> cards that could be used but you are still limited when you get
> into 4+ axis with full limit switches.

What if you went 8 or 16-port? Yeah, I can see a mess of cables
too. Not ideal I assume. ;-PPP

> I've been kicking around the idea of designing a PCI card to do
> CNC I/O with. So about a month ago, I decided to commit $$$ and
> time to it. The card will be a 32 bit PCI card with lots of on
> board memory for step buffer, timers, counters, encoder interfaces,
> spindle interfaces and lots of auxillary I/O.

There has gotta be some company out there that alreads has
everything needed in a PCI card (again, check out Sea Level Systems'
products and get back to me).

> The design has been started and if all goes well, in a couple of
> months I'll have the first prototypes running. I'm thinking 6
> axis but 8 axis might make it in there. It will support steppers
> as well as servos and could even be used to run steppers in closed
> loop mode with encoders.

Man, I really need to get on the ball on this.

> I'm also talking to a DSP guru buddy of mine about adding a DSP
> chip to it. I'm not a DSP expert but can see how an off board
> DSP could help in some of the calculations CNC requires.

I keep hearing DSP mentioned as viable. I really need to learn more
about the end devices. My experience has been limited to little
more than async I/O and relay toggles.

> The PCI card will cable to a breakout box where all of the
> connections to the real world will be. I'm kicking around the
> idea of an optical interface to the breakout box.
> If not optical it'll be differential to the breakout box for
> noise immunity.
> I'm going to try to do it right. My hope is to end up with an
> interface with an open API that anyone that wants to can write
> code or drivers for that will be a viable interface
> for several years to come. But one that is affordable to build.

I'm a COTS type of guy, but if you can best whats available, go for
it!

> Linux and EMC is not my first priority. I prefer Windows.

No problem. I just do a lot of GNU development, from Linux
servers/desktops to VxWorks/Linux embedded devices. One toolchain,
endless choices for chips, operating systems and environments. Of
course I could also get GCC for Windows via Cygwin, but why run on a
non-native platform?

> But I'm sure I'll find someone that will be willing to write
> Linux drivers for it.

If the specs are available, you can be sure of it. ;-PPP

> If nothing else, I'll finally have the interface I have wanted
> for years.

And I'm on the other part of the spectrum, I'm still trying to
figure out what kind of interfaces are used. ;-PPP

-- TheBS

--
Bryan "TheBS" Smith mailto:b.j.smith@... chat:thebs413
Engineer Absolute Value Systems, Inc. http://www.linux-wlan.org
President SmithConcepts, Inc. http://www.SmithConcepts.com