Re: EMC compatible computers

[John Sheahan <jrsheahan-at-optushome.com.au>]

On Tue, Jan 14, 2003 at 10:11:16AM -0500, jmkasunich-at-ra.rockwell.com wrote:
> Yes, and for PC to PC comms, ethernet is the right choice.
> 
> But how does the second motherboard (presumably running
> DOS to generate step pulses) send those pulses to the
> motors?  If you use the parallel port, then you are still
> facing the "obsolete" factor.  If not parallel port, then
> what?

My picture is a small, dedicated  box near the machine.  
If its a standard motherboard - with a parallel port, thats ok.
If its a dedicated chunk of hardware - say a fpga, electrically its a
lot like a parallel port.  
Either way its essentially co-located with the  motor driver.  

> 
> > The cost of interfacing to either
> > is tiny compared to other related costs.
> 
> "other related costs"?  With today's step and direction
> parallel port systems, "other related costs" are usually
> nothing more than a breakout board - and even that is a
> luxury - you could cut one end off of the parallel port
> cable and wire it directly to the drives.

I was including the motor driver and perhaps the machine..


> 
> > And the parallel port (electrical) performance sucks
> > compared to any ethernet - particularly optical ones.
> 
> Do you mean isolation?  Any other "performance" measure
> is irrelevant for CNC - if you only need 2Mbs, then
> 100Mbs is not better, just more expensive.
> 

isolation/noise/esd in general. I think the 10 / 100 argument
is fairly null today - 
its hard to buy  NICs that do not handle both, for not 
a lot of $. GbE over fibre still works better in a particularly noisy 
environment.  Even retry adds latency.
 
And 100 does reduce latency over 10 a bit - if thats relevent.

parallel ports can't drive long wires, have lousy edge rates, 
die from ESD, and very occasionally miss transfers.  
I builtsome  ROM emulators a while back.  some parallel ports 
lose the occasional transfer. (order of 1 in 10^6). some are better.
that was with schmitt triggers and decent waveforms.

I just dislike parallel ports! :)


> >> All the real time and close to the real
> >> time apps are handled by DOS (Free DOS).
> >> Front end is  handled by  Linux.
> 
> > DOS isn't real time.   perhaos using interrupts is
> > but then rtlinux would work just as well.   And is
> > more future-proof i think.
> 
> Yes.
> 
> > Still - it seems to me offloading the hard real time
> > to an offboard processor is nice. the interface to it
> > is a lot less important.
> 
> Any real time stuff that RTLinux or RTAI on a Pentium
> can't handle won't be handled by DOS on a 386 or anything
> on a low cost microcontroller.  The real burden is step
> pulse generation and encoder counting.  That is best
> handled by dedicated hardware, not software of any kind.
> 

agree, although modern PC's are quick enough to blur the difference.


> >> Dos can be serviced by a 386 single board PC.
> >> Linux - some kind of a Pentium.
> >> Software cost - 0. Hardware - not very high.
> 
> > If I have learned anything - in small qty the sw cost
> > is higher than the hw cost.  in large qty this reverses.
> 
> Yes, except - if you can use software that is already
> written without modification, then its cost depends only
> on licensing - with the right license, the cost can approach
> zero even in low qty.
> 
> For hobbyists, design costs (software or hardware) are
> often hidden, and if the design is "fun", we may consider
> them to be zero.  Acquiring the actual hardware, on the
> other hand, almost always requires money.
> 

agree with the first, but I still prefer designs that 
hang in there over time..  PC hardware is just so ephemeral compared 
to the stuff its controlling, particularly now. 

used motherboards suitable for emc are generally in the 
free category now.  
fpga based proto boards are not unfortunately.

john



> John Kasunich
> 
> 
> 
>