If you're using a PC I tend to prefer one of the LINUX RTOS flavors. Even
Ubuntu has an RTOS kernel. The ENC2 folks use it for their distro. If your
using an embedded solution then I like the QP framework or you can use an
RTOS made for your uController. The latency issue can arise even in a para
port controller. This is why EMC2 uses the Ubuntu RTOS kernel. USB does
have a high speed version that is supported under windows. However, this
only garuanties that the device will be polled in a timely manner as short
as 125 micro-seconds. This can get slower for chained devices and can be
interrupted by high priority OS interrupts. So most USB controllers will
buffer the data to allow for this.
Parallel ports are much easier to use. They require no drivers and in some
OSs can be addressed directly. They are great for simple low current
devices and can be used to generate high voltages by voltage multiplication
for programming small devices. However, their standards are loose and you
can never count on the implementer to have followed the standards. Still
they are/were popular for hardware hackers because of their simplicity,
ease of programming, ruggedness and popularity on PCs. However, they are
getting harder to find and because of this, hardware hackers are going to
be forced to pick up the USB interface as a viable communication interface
to their devices.
There is some help here. The FTI devices have default configurations that
can allow the device to function as a serial or parallel port right from
power up. Some devices actually look like a generic 8 bit port and can be
programmed via the USB cable. So in this case there is no need for a
uController. USB is booth a Software and Hardware implementation. However,
their are APIs in most OSs (even a lot of uC RTOSs) and there are libraries
for writing to USB. A little more knowledge is needed than was required for
the serial and parallel ports however, there are also gains to be had. Like
everything, there are trade offs.
If you've not done any USB coding I'd suggest getting a good book on the
subject. Or read a few online tutorials before choosing it as your
interface. Or take the easy route and use a virtual COMM or Printer port
and a smart USB device on your project board.
I believe that in most cases the move to USB is well worth the gains.
However, in areas where timing is important it does leave some issues to be
resolved. Most can be dealt with by using high speed or burst mode data
transfers and buffering on the device. Sometimes however, USB simply isn't
the right choice.... This is when a bus that supports true interrupt or
real time capabilities is required.
On Wed, Jun 27, 2012 at 9:59 AM, DENNIS SHELGREN <nojoeco@...>wrote:
> ∗∗
>
>
> I've always been interested in RTOS's, mostly because I'm used to
> programming before the whole multitasking thing anyway.
> Did you have one in mind for a usb application?
> I was considering a similar process for a cheap solution for another
> stepper and solenoid device(diy thermal solar).
> It's possible to run usb under DOS and there are open source cnc programs.
> Perhaps a patch could reroute the signals through a usb layer.
> Of course this just me thinking out loud. I'd have to dig out a laptop that
> had those programs on it and see if the usb dos driver causes hiccups in
> the cnc program first.
>
>
> On Wed, Jun 27, 2012 at 6:45 AM, Randall Morgan <rmorgan62@...>
> wrote:
>
> > 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]
> >
> >
> >
> > ------------------------------------
>
> >
> > Be sure to visit the group home and check for new Links, Files, and
> Photos:
> > http://groups.yahoo.com/group/Homebrew_PCBsYahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
--
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]