Re: EMC compatible computers

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

There is a possibility of another hardware model without a  high cost.
Consider a controller which consists of several low-speed mother boards
connected together
either through the parallel data link or the ethernet. All the real time and
close to the real
time apps are handled by DOS (Free DOS). Front end is  handled by  Linux.
DOS
can be serviced by a 386 single board PC. Linux - some kind of a Pentium.
Software
cost - 0. Hardware - not very high.
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
>
>
>
>
>
>