Re: EMC compatible computers

[Ray Henry <rehenry-at-up.net>]

On Monday 13 January 2003 06:35 pm, Phil wrote:
<s>
> 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've got a couple of these boards now.  The BDI TNG recognizes most all 
of the hardware and even does a tolerable job with the Trident CyberBlade 
display driver.  One of the boards has two ide headers the other one ide 
and one floppy.  Both can be setup for netboot.  Both have a single pci 
slot that can be used with the EMC for a servo card like the Vigilant or 
for a DIO card. 

I used one of these from www.idot.com as a built in pc for a recent set 
of articles in HSM with Roland Friestad.

I'd think that these would be great machine controllers in a work cell 
that required several.  They could all be directed by a single PC that 
ran all of their gui's.  That way robot arms or pallet shifters could 
anticipate their next moves and would coordinate the entire cell.

Ray



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