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

From: "Bryan-TheBS-Smith" <b.j.smith@...>

> Interface options, headless boxen, and remote control ...

Awrr?

> The "die-hard" interface standard, I'm a fan of RS-422 for when you
> gotta go hundreds of feet. On the PC platform, I love the fact that
> your typical 16550-series UART is a fairly standardized interface.
> Using $50-300 2-4 multiport ISA _and_ PCI boards (many of which are
> supported by Linux -- including newer PCI ones) in PCs allows you to
> control quite a number of devices -- and I would assume this is the
> most "clear-cut/compatible" option for interfacing with various
> systems. Especially since RS-232/422 isn't dying anytime soon
> despite the advent of USB -- and just about any microcontroller can
> handle serial I/O.

Okay ig'nant guy question -
What's the diff between RS-232 and RS-422?
And if you put in add-in parallel port boards, can you
give EMC more output options?
(like telling the plasma torch when to trigger? Or actually doing the
triggering)

> As someone introduced to me in another thread, your typical PC
> gameport that uses PC/AT I/O ports 200-201 hex will give you at
> least 4-axis control and four digital ("button") toggles. Although
> I have never done any MIDI/Gameport control/programming myself,
> Brian Pitt mentioned that the protocols are really little more than
> isolated serial interfaces. The only thing that worries me is that
> the MIDI/Gameport approach will becomes less common as USB gains
> ground.

May-be, but I've a like ten sound card/game port ISA cards laying around
here
and know where I can pick up about 30-35 more pretty cheaply.
Now knowing abso-frigg'n-lutely *nothing* about PCB's or designs,
wouldn't it be possible for some of those that do make them to
make some that slip in an ISA slot and have a game port interface?
Remember, I completely dumb about this.

> Worse yet, while extra
> parallel ports can be installed and well supported via ISA cards,
> PCI-based parallel port cards are usually non-standard and Windows
> 9x/ME only (NT/2000 drivers if you are lucky). And like
> MIDI/Gameport, I'm afraid that it too will becomes less common as
> USB gains ground.

Actually, I know a guy that I just found out his daily job is
to do nothing but write drivers (wrong word in LinuxLand?)
for Linux at the company he works.
He might be interested in writing something for us.
I can ask after we get the details sorted out, I suppose.

> - HEADLESS EMC BOXEN AND REMOTE CONTROL
>
> I'm a _big_fan_ of the "plug-n-play, black box" concept. Although
> operating systems with a GUI requirement, like Windows, will _never_
> be good embedded operating systems for things outside of PDAs and
> desktops, Linux (among BSD, VxWorks, QNX, etc...) will continue to
> excell. My favorite "pasttime" is to build all kinds of specialty
> Linux boxen, and "pre-build" software distributions that are
> self-contained, headless (i.e. no monitor/KB/mouse) and completely
> administered remotely via either web browser, terminal interface
> and/or remote display (like with X-Windows and/or VNC) --
> _regardless_ of what OS the user interface/display runs.
> I think this "headless boxen" approach is ideally suited for a
> Linux-based EMC system. The physical EMC system is a simple PC (of
> whatever form-factor), with a network interface card (NIC) for
> connection to the user interface system (another PC running any OS),
> along with a plethora of component interfaces -- e.g., at least 2-4
> RS-232/UART-driven serial ports, and/or [an]other, well-supported
> interface(s) (see above). At the very least, we should be
> recommending some "reference EMC system design/configurations" for
> doing CNC with such "headless boxen."

WOW~! I like this idea.
But you'd still have to have *some* controls at the machine, no?
Like jog buttons, E-stop, pause and start (next), etc...


Weyland