There has been a lot of talk lately on the list promoting the development of
some "smart hardware" to supplement the PC's poor performance. The second
item that is rearing its ugly head is that pc's are rapidly losing their ISA
slots and their serial/parallel ports. I also subscribe to the usb-devel
list and am getting a pretty good feel for what usb is capable of. I use EMC
as the PC end smarts. It basically works well as an open source gcode
interpreter that expects to output a drive signal and receive back an
encoder signal for each axis every 1ms or so (programmable). The usb bus can
be thought of as a fast 12mb/sec serial port (about 1/2 of this is actually
usable). I am starting to think along the lines of a usb board that contains
some number of rate generators (like Marriss's DDS system or even pic based
software DDS) to generate the stepper drive signals smoothly and the same
number of encoder interfaces (either in hardware counters or possibly pic
based software interfaces). The interface would use an isosyncronous read
port and a write port to read/write the command/status signals every ms. A
four channel card would cover most applications although once design is a
little further along, it may be possible to put 6 axis on a card and produce
them in various states of population. USB support is getting pretty good
under linux, with quite a few example drivers. Between the lists, there is a
lot of talent available... where to we need to be in a year from now? Would
USB make sense in a shop environment for getting machine control information
in/out of the computer?
Would DAC outputs for servos make sense? Would +-50ma outputs make sense for
driving hydraulic servo valves? How much would the board cost to produce? It
is going to be hard to beat the cost of an add-in parallel port. The card
would definitely make laptops or low end Macs like an iMac attractive as a
dedicated controller. Just some ideas to think about for the next generation
cnc controllers.
=======================================================
Lawrence Glaister VE7IT email: spam_OUTlgTakeThisOuTjfm.bc.ca
1462 Madrona Drive http://jfm.bc.ca
Nanoose Bay BC Canada
V9P 9C9
=======================================================

USB speakers use "isochronous" USB transfers. Iso transfers
don't do error-correction; they're specifically for
streaming-type applications where "guaranteed" delivery of data
is more important than actual data integrity ("guaranteed" is in
quotes because it's only really guaranteed under a real-time
operating system, not under Windows).

Also, iso support on the host (i.e., PC) side is EXTREMELY
difficult to implement; "bulk" or "interrupt" transfers are MUCH
easier.

A USB CNC controller would use bulk or interrupt transfers and it
would only need to transfer a relatively small amount of data
once per millisecond or so.

> I think you need to have enough autonomous intelligence to handle the
> inevitable 'misses' from the PC end, especially when running any
> flavor of Windoze.

You're absolutely correct; Windows DOES have problems with
real-time operations. The easiest way to show this is to just
click the Windows Start button while doing a USB loopback test
or something; the USB traffic may pause for a few SECONDS while
the Start Menu is drawn.

However, there ARE other operating systems, and USB stacks are
available even for DOS. I don't think it'd be hard to build
a special-purpose CNC controller that used USB as the interface
between the PC and the machine.

All USB transfers have their pro and cons. For this case i'd go with
Interrupt transfers with polling intervals settable between 1 to 255mS it's
more predictable then Bulk which is allocated more or less transfers
depending on bus loading.

To cater for bad or missing packets, allocate enough buffer space on the
device or send data 4-8 times faster then what's required or what your
buffer can hold and NAK host transfers till buffer space frees up.

>Bob Ammerman <.....PICLISTKILLspam.....MITVMA.MIT.EDU> wrote:
>
>> Have you ever heard USB speakers stutter?
>>
>> Think what might happen to your hardware if a USB driven servo/stepper
>> 'stuttered'.
>
> Bob:
>
> USB speakers require LOTS more data, LOTS faster, than a CNC
> machine does.
>
> USB speakers use "isochronous" USB transfers. Iso transfers
> don't do error-correction; they're specifically for
> streaming-type applications where "guaranteed" delivery of data
> is more important than actual data integrity ("guaranteed" is in
> quotes because it's only really guaranteed under a real-time
> operating system, not under Windows).
>
> Also, iso support on the host (i.e., PC) side is EXTREMELY
> difficult to implement; "bulk" or "interrupt" transfers are MUCH
> easier.
>
> A USB CNC controller would use bulk or interrupt transfers and it
> would only need to transfer a relatively small amount of data
> once per millisecond or so.
>
>> I think you need to have enough autonomous intelligence to handle the
>> inevitable 'misses' from the PC end, especially when running any
>> flavor of Windoze.
>
> You're absolutely correct; Windows DOES have problems with
> real-time operations. The easiest way to show this is to just
> click the Windows Start button while doing a USB loopback test
> or something; the USB traffic may pause for a few SECONDS while
> the Start Menu is drawn.
>
> However, there ARE other operating systems, and USB stacks are
> available even for DOS. I don't think it'd be hard to build
> a special-purpose CNC controller that used USB as the interface
> between the PC and the machine.
>
> -Andy
>
>
>=== Andrew Warren - EraseMEfastfwdspam_OUTTakeThisOuTix.netcom.com
>=== Fast Forward Engineering - San Diego, California
>=== http://www.geocities.com/SiliconValley/2499

> USB speakers use "isochronous" USB transfers. Iso transfers
> don't do error-correction; they're specifically for
> streaming-type applications where "guaranteed" delivery of data
> is more important than actual data integrity ("guaranteed" is in
> quotes because it's only really guaranteed under a real-time
> operating system, not under Windows).

also right.

> Also, iso support on the host (i.e., PC) side is EXTREMELY
> difficult to implement; "bulk" or "interrupt" transfers are MUCH
> easier.

absolutely true.

> A USB CNC controller would use bulk or interrupt transfers and it
> would only need to transfer a relatively small amount of data
> once per millisecond or so.

can't use bulk: bulk has _NO_ thruput guarantees on USB.

interrupt is probably the way to go.

> > I think you need to have enough autonomous intelligence to handle the
> > inevitable 'misses' from the PC end, especially when running any
> > flavor of Windoze.

> You're absolutely correct; Windows DOES have problems with
> real-time operations. The easiest way to show this is to just
> click the Windows Start button while doing a USB loopback test
> or something; the USB traffic may pause for a few SECONDS while
> the Start Menu is drawn.

what kind of USB traffic are we talking about here??!??

> However, there ARE other operating systems, and USB stacks are
> available even for DOS. I don't think it'd be hard to build
> a special-purpose CNC controller that used USB as the interface
> between the PC and the machine.

yeah... but if you're gonna use DOS ...

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

> > A USB CNC controller would use bulk or interrupt transfers and
> > it would only need to transfer a relatively small amount of data
> > once per millisecond or so.
>
> can't use bulk: bulk has _NO_ thruput guarantees on USB.
>
> interrupt is probably the way to go.

True, Bob... But under Windows, there are no guarantees even for
interrupt transfers.

Fortunately, it's unlikely that a CNC-controller PC will have a
bunch of other bandwidth-sucking devices on its USB bus, so
there'll probably be plenty of bandwidth available for either
bulk or interrupt transfers.

> > click the Windows Start button while doing a USB loopback test
> > or something; the USB traffic may pause for a few SECONDS while
> > the Start Menu is drawn.
>
> what kind of USB traffic are we talking about here??!??

> Fortunately, it's unlikely that a CNC-controller PC will have a
> bunch of other bandwidth-sucking devices on its USB bus, so
> there'll probably be plenty of bandwidth available for either
> bulk or interrupt transfers.
>
> Windows Me and Win2K are better than Win98... But even on those
> newer OSes, there are still LONG pauses.
>
> -Andy

Buffering would be the key.

The only thing that would bother me is control of an emergency stop feature
from windows. Better to have a kill switch NOT controlled by a bloated OS.

>
> > Fortunately, it's unlikely that a CNC-controller PC will have a
> > bunch of other bandwidth-sucking devices on its USB bus, so
> > there'll probably be plenty of bandwidth available for either
> > bulk or interrupt transfers.
> >
> > Windows Me and Win2K are better than Win98... But even on those
> > newer OSes, there are still LONG pauses.
> >
> > -Andy
>
> Buffering would be the key.
>
> The only thing that would bother me is control of an emergency stop feature
> from windows. Better to have a kill switch NOT controlled by a bloated OS.
>
> -Robert Severson
> http://usbsimm.home.att.net
> http://www.jged.com
> http://www.annatechnology.com
>

Antonio L Benci wrote:
>
> This combination seems to work for me:
>
> PC98 -> USB to RS485 interface -> CNC system.
>
> As the CNC system is not a high bandwidth system the 9600bps RS485 end
> does not load the buss.

Hi Antonio, what about CNC drivers that require
the industry standard step/dir pulses that
must be at exact and often quite high frequencies?

Like 3 pulse streams of differing f at 10kHz to
40kHz that need exact pulse timing?
There is only a few bits, but high speed timing
is critical.

Would USB handle this? This is quite possible
through parallel port in dos environment but I
would be worried about timing using USB..?
-Roman

Roman Black wrote:
>
> Hi Antonio, what about CNC drivers that require
> the industry standard step/dir pulses that
> must be at exact and often quite high frequencies?

For this particular scenario we would use a PCI Stepper Indexing card.
We operate
several systems with different modalities. The simplest is individually
addressed RS485 indexers for each motor where speed is not of the
concern. High speed systems use PCI/DSP based indexing cards.

>
> Like 3 pulse streams of differing f at 10kHz to
> 40kHz that need exact pulse timing?
> There is only a few bits, but high speed timing
> is critical.

We NEVER rely on the PC for accurate timing requirements ;-)

>
> Would USB handle this? This is quite possible
> through parallel port in dos environment but I
> would be worried about timing using USB..?

So long as the timing requirements are not USB dependant. A programmable
indexer which communicates via USB to a PC would be fine...

Yes... Too many experiences where Windows has faulted (so specific
reason) and the timing has been corrupted. We have used a fault tolerant
DOS system using the DOS timer with little or no problems. I don't
really trust WinXX for systems where fail-safe operation is required
such as a CNC system.

>
> > So long as the timing requirements are not USB dependant. A programmable
> > indexer which communicates via USB to a PC would be fine...
>
> Obviously using separate indexer would solve the
> problem, what I really wanted to know is can you use USB
> for high speed accurately timed output?

> In response:
>
> Roman Black wrote:
> >
> > Antonio L Benci wrote:
> >
> > > We NEVER rely on the PC for accurate timing requirements ;-)
> >
> > Any reason??
>
> Yes... Too many experiences where Windows has faulted (so specific
> reason) and the timing has been corrupted. We have used a fault tolerant
> DOS system using the DOS timer with little or no problems. I don't
> really trust WinXX for systems where fail-safe operation is required
> such as a CNC system.

Amen and amen.

My rule of thumb is:

Windows (any flavor) - latency of _seconds_

Dos (w/disk access) - latency of many _milliseconds_

Dos (no disk access) - latency of a few _milliseconds_

Bare x86 iron running my own RTOS - latency of few _microseconds_.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

> > We NEVER rely on the PC for accurate timing requirements ;-)
>
> Any reason??
>
>
> > So long as the timing requirements are not USB dependant. A programmable
> > indexer which communicates via USB to a PC would be fine...
>
> Obviously using separate indexer would solve the
> problem, what I really wanted to know is can you use USB
> for high speed accurately timed output?

Actually USB is specified to have its own accurate 1mS clock. It is
specifically intended for "dumb" USB devices to use as an accurate clock.