Re: EMC compatible computers

[Phil Wilshire <philwil-at-earthlink.net>]

Hi All,

AS a software professional I hope that all software does not carry a 0
cost !!!!

I would also suggest keeping RTlinux as the OS for the Low end stuff.

It needs a bit more resources but has all the interfaces you need.

This also means that you can keep one OS in the whole system.


I am looking at using some of the new VIA mini itx boards as remote
control engines
On a dedicated Ethernet Link, using UDP ( connectionless ) transactions,
this 
becomes a very fast and cheap system.


I still like the firewire parallel port..

regards
  Phil Wilshire


alex wrote:
> 
> 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
> >
> >
> >
> >
> >
> >

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768