Re: EMC compatible computers

["alex" <telecomt-at-tht.net>]

John,
I liked very much what you said - makes lots of sense.
Alex
----- Original Message -----
From: <jmkasunich-at-ra.rockwell.com>
To: Multiple recipients of list <emc-at-nist.gov>
Sent: Monday, January 13, 2003 4:33 PM
Subject: RE: EMC compatible computers


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