No, what I am describing is sending the step data not the GCode which has
to be interpreted and compiled into step commands. It can be done using a
RTOS but under a non RTOS it requires either extra hardware buffering.
On Wed, Jun 27, 2012 at 6:34 AM, Tony Smith <ajsmith1968@...> wrote:
> ∗∗
>
>
> > 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
>
>
>
--
If you ask me if it can be done. The answer is YES, it can always be done.
The correct questions however are... What will it cost, and how long will
it take?
[Non-text portions of this message have been removed]