RE: EMC compatible computers

[jmkasunich-at-ra.rockwell.com]

Ramblings on the subject of external step generator hardware and the
interface to such, whether USB, ethernet, parallel port, firewire, etc.

Raw wire  (or fiber optic) speed is only half of the equation.  Those
speeds are only approached with large packets.

With Ethernet, a packet contains addressing information, the data (usually
a
block of several to many bytes), and a CRC for error detection.  So sending
10 bytes of data may generate a 20-30 byte packet, and reading back data
will require another packet.

With packet based protocols - USB, Ethernet, Firewire - the external unit
would need a microcontroller of some type to unpack the packets and
write the data to the hardware, as well as to assemble packets for return
to  the PC.  That adds cost, hardware design effort, and firmware design
effort.  Something like the Packet Whacker could be very useful, but it
still needs a micro to control it.
http://www.edtp.com/packetwhacker.htm

Increasing the wire speed from 10Mbs to 100Mbs and higher reduces the
length of time the packet actually spends on the wire from 20-30 uS to
2-3uS
or less, which is almost irrelevant.  What matters is the turnaround time
at
each end, the time spent in device drivers, servicing interrupts, and so on
to set up each packet.  Remember that even if you have 2GHz Pentium at
the PC end of the line, the other end will be low cost hardware.  Maybe a
PIC
or some other 8 bit micro.  So turnaround will always be at least tens of
microseconds, even if the packet is actually sent at blazing speed.

In fact, at 100Mbs, and certainly at Firewire speeds, the little
microcontroller
won't be able to feed the data to the wire anywhere near fast enough - the
interface chip will have to buffer the entire packet.  At gigabit speeds,
an
entire 30 byte packet is send in the time it takes many microcontrollers to
execute 3-4 instructions.  The real benefit of blazing speed is when
transferring
large amounts of data in big packets, not when sending small amounts of
data that need low latency.

In contrast, data on the parallel port is transferred one byte at a time.
There
is no need for _any_ intelligence in the external device.  (See Jon Elson's
system - there is no microprocessor or software on his board.)  Simple
logic can address the data registers of the step generator hardware, and
each byte is written to that hardware as soon as the PC software writes it
to the parallel port register(s).  The software can read 3 bytes, then
write 2,
then read 20,  etc., with no overhead.  Each byte takes about 1/2 uS,
perhaps
longer depending on the external hardware, but never longer than several
microseconds.

I expect that 10Mb, 100Mb, Gigabit, and Firewire can all meet the under 1mS
requirement for EMC (actually under 500uS would be better), as long as a
dedicated link is used for real time data to avoid collisions.  However
they
will require more hardware and firmware to do it as compared to the
parallel port.  The only technical advantage of the packet protocols is
electrical isolation.  Obsolesence of the parallel port may drive us to
these
other technologies, but when it does, hardware cost will increase.

Of all the ideas mentioned lately, I still prefer the parallel port for the
simplicity
and elegance of the external hardware.  No micro, no firmware - it's almost
like an extension of the PC's internal bus, only a little slower.  My
second
choice is Ethernet.  It is a well defined, mature, open protocol that is
readily
available in PCs and will probably remain available for quite a few years.

John Kasunich






Dave Lantz <dlantz-at-armorholdings.com>-at-nist.gov on 01/13/2003 03:07:11 PM

Please respond to emc-at-nist.gov

Sent by:    emc-at-nist.gov


To:    Multiple recipients of list <emc-at-nist.gov>
cc:
Subject:    RE: EMC compatible computers



my math puts it at (aprox) 1/2 the par-port speed (ECP=2MB/sec) 10 base t =
10Mb (bits!!!) /sec divided by 8 = 1.25 MB (bytes)/sec, 100baseT would give
you 12.5 MB/sec and gigabit (over copper cat 6 wire) would give you
125-250MB/sec.  The hard part for me to figure out was that there are 8
bits
in a byte...---dave

-----Original Message-----
From: Dave Engvall [dengvall-at-charter.net]
Sent: Monday, January 13, 2003 2:52 PM
To: Multiple recipients of list
Subject: RE: EMC compatible computers



Jon,
Did I miss  something. Isn't 10 Mb ethernet about as fast as the parallel
port?

Dave Engvall

-----Original Message-----
From: emc-at-nist.gov [emc-at-nist.gov]On Behalf Of Jon Elson
Sent: Monday, January 13, 2003 10:31 AM
To: Multiple recipients of list
Subject: Re: EMC compatable computers





John Sheahan wrote:

>sorry for the abbreviation  GbE == Gigabit Ethernet
>often run on fibre - which may be appropriate for noise reasons here.
>
>I don't see the extra speed as a bonus for this app.
>
>
>
Note that ALL ethernets, thick-wire, thin-wire and twisted-pair, are
electrically isolated
by transformers.  If there was no other traffic on the ethernet segment,
I think even
10 Megabit/sec ethernot would work for this application.  100 MB/S would
definitely
be sufficient.  With proper attention to keeping the protocol simple, I
would think a
message to each axis drive would only be a couple of bytes, so each
message could
be just tens of microseconds long.

Jon