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

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

- INTROS ...

Hi! First off, if you haven't noticed (from my other posts), I'm a
newbie to all this CNC-EMC "schtuff." I'm an EE with a history of
software design in aerospace and systems software (like embedded
data acquition and networking) combined with some limited integrated
circuit design (namely simple 8-32-bit microcontrollers of the
Motorola variety). I also have a buttload of Windows and UNIX
sysadmin experience (mainly from my college days, although most
engineers prefer to ask a fellow engineer for help than the IT
department, and I find I "stump" MCSEs everytime ;-).

I'm trying to absorb a lot of new information in a matter of days.
I find the whole CNC-EMC approach to machine control and automation
facinating, most of which I didn't know about until Weyland posted
on my local LUG (Linux user group) list. Although I understand how
stepper motors work, am familar with various, low-cost
microcontrollers (e.g., PIC, 6800, etc...) and prototype boards and
systems, etc..., I never realized just how easily one can bring the
power of all these systems to create a SOHO (small office/home
office) "machinist shop."

Most of all, I was totally unaware that there was a lot of existing
NIST code written for the GNU Compiler Collection (GCC), with Linux
being a popular platform. Being both an avid Linux user (for just
about everything), an EE who wished he majored in ME in college, as
well as a man who is always wishing he could bend and cut sheet
metal for electrical enclosures and packaging (yes BAY-BEE!!!),
having a home CNC-EMC setup would be ideal. Again, bare with me as
I "come up to speed" on all the details.


- EMC-TO-COMPONENT INTERFACE OPTIONS

While I research more into motors and CNC components, I see many
people talking about interfaces and controls. Some talk about the
keyboard and USB interfaces. Spending several years doing real-time
software development using serial (RS-232/422) and Ethernet
interfaces, I am curious as to what interfaces people are using for
their systems. I'm particularly curious (and worried) about all the
interest into USB, which I have found out first hand, is a
piss-poor, underdocumented and non-standard bus that is a victim of
gross mis-interpretations by different vendors. But more on that
under USB below.

RS-232/422

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.

MIDI/Gameport

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.

IEEE 1284 / Bi-directional Parallel

Be it your typical BiDi parallel or full-up IEEE 1284, I feel that
parallel ports are more "standard" than USB when it comes to
software -- and can be just as fast or faster. With 8 parallel data
lines, it is just about as close to a GPIO (general purpose I/O) bus
as you can get without building a prototype board with a
microcontroller driving it. Unfortunately, not all microcontrollers
are designed to handle parallel I/O -- which make mean it is not
ideal for most application-specific devices. 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.

IEEE 488 / GPIB (General Purpose Interface-I/O Bus)

My understanding of GPIB is strictly from a "user" standpoint. Must
of the lab and scientific work I have done has usually been by using
a PC connected to various equipment via GPIB (with a GPIB controller
in a PC). So I'm totally ignorant when it comes to being
knowledgable about how GPIB works. What I "assume" is that GPIB is
more than just an interface, but more of a networking interconnect
between systems (with GPIB able to control 8-32 systems?, using a
"double-sided connector" at the host?). As such, I "assume" it is
not for driving and controlling "dumb" components but complete,
"intelligent" systems. In such cases, Ethernet could serve the same
purpose and is outside of the interest of CNC-EMC (except for
connecting to the EMC system itself -- more below).

USB (Universal Serial Bus)

What can I say, I _hate_ USB. It is like RS-232 without the PC UART
standard -- many device vendors interpreting and using the bus in
ways that often conflict with each other. It was designed as a
simplistic, "quick-to-market" standard where the host controller
design and host controller driver would be easy, putting the "meat"
(and the subsequent "hard parts") on the end-device vendor (and its
driver). No wonder it was designed by Intel and Microsoft, the #1
controller vendor (in its chipsets) and the #1 driver vendor (in its
operating systems), respectively. And even when vendors "band
together" to create device-specific standard, most don't follow them
-- e.g., ACM for USB modems -- only 25% adhere to it (and even new
ones don't). And even the USB-to-RS232 "bridges" fail to support
CTS, DTR and other status lines (even in the Windows drivers, let
alone the Linux ones!).

IEEE 1394 / FireWire

Simply put, I love FireWire. Way too many storage and high
transfer devices are being made available in USB, which is a
bottleneck (max 12Mbps/1.2MBps) and a CPU utilization nightmare
(because it is programmed I/O, PIO), where FireWire is a perfect fit
(400Mbps/50MBps, direct memory access, DMA). Even Intel has had
trouble getting USB 2.0 to even get close to its max DTR
(480Mbps/60MBps), because of the programmed I/O focus, and FireWire
will continue to be a better choice. Unfortunately, FireWire is
like SCSI, not commodity, and Intel's renigging on putting FireWire
in its chipsets have caused this. And when regarding CNC-EMC, we
are talking about low-speed transfer rates for control (where
response times are more important). As such, FireWire is _overkill_
for these applications (and component microcontrollers wouldn't be
able to deal with FireWire).


- 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."

The software utilized by the EMC system is a customized Linux
distribution -- ideally based on a popular Linux distribution like
RedHat or Debian. Customization would include an
application-oriented RTLinux kernel, a complete compiler/development
suite, network filesystems for easy "file upload/download" (Samba
for Windows clients, NFS for UNIX clients -- possibly a FTP and/or
HTTP server) and, most importantly, remote access services (SSH for
remote terminals, VNC for remote graphical display). Given time and
support, a full web-based configuration suite could be developed,
but that would be secondary to getting just a working "black box"
distro running (SSH and VNC work good enough for most experienced
Linux users).


Just some ideas. I'm still learning here and checking out the
Penguin CNC release as I speak. I'm sure some of this has already
been covered/suggested, but I was just curious as to why people keep
bringing up keyboard/USB interfaces when multiport serial cards
aren't that expensive (and RS-232/UART is just so much more
flexible!). Again, please excuse any newbie "ignorance" here on my
part.

-- 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