Homebrew PCBs

> USB can be used in an interrupt driven system. For example a timer can be
used
> to to generate a periodic interrupt to trigger the usb data to be sent.
Just as can
> be done with a parallel or serial port. In the case of directly driving
steppers the
> periodic time constant must be low enough or the stepper controller must
be
> smart enough to buffer enough incoming data to last until the next data
> transmission. Even smarter hardware might send an interrupt request to the
PC
> to request more data to fill it's buffer.
> 
> A good demo of this was done in the Windows port of EMC2 RTS. Here a
> Windows XP, Vista, or 7 host uses the USB port to send data to a PIC uC to
be
> buffered. The step data is then used to drive the motor steps. The data
transfer
> rate is plenty high enough but the period between transfers is the issue.
Under
> Linux, USB can be accessed at a lower level then under Windows and results
in
> lower transmission latency.
> 
> Playing Devil's advocate I'd say that RTOSs in uC devices can and do
provide
> almost identical access to hardware USB as they do to parallel ports....
But on
> the PC level you are right in that the OS allows much lower level access
to the
> para port.


That's the grumble people have, USB isn't as simple as parallel.  The
hardware your describing already exists (Smoothstepper, Flashcut etc), and
there are even Ethernet versions.  Some people even use Arduinos for that.

The PC just dumps the g-code to the hardware, and the hardware controls the
mill, not the PC.  That's the way CNC used to be, with g-code drip-fed via
RS-232.

The basic point is that direct control of CNC via USB isn't feasible, the
messaging stack introduces delays that makes it unreliable.  Window, Linux,
Mac; they've all got the same problem.  

Even if it does work ok, someone plugs in something extra... and the OS go
off to handle that.

Some people just don't like having to spend an extra $300 when the parallel
port works just fine.

Tony