Searching \ for '[EE]: USB stepper drive system' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/steppers.htm?key=stepper
Search entire site for: 'USB stepper drive system'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: USB stepper drive system'
2000\12\19@222741 by Lawrence Glaister

flavicon
face
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_OUTlgTakeThisOuTspamjfm.bc.ca
1462 Madrona Drive                     http://jfm.bc.ca
Nanoose Bay BC Canada
V9P 9C9
=======================================================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\20@082436 by Bob Ammerman

picon face
Have you ever heard USB speakers stutter?

Think what might happen to your hardware if a USB driven servo/stepper
'stuttered'.

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.

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

{Original Message removed}

2000\12\20@123441 by Andrew Warren

face
flavicon
face
Bob Ammerman <.....PICLISTKILLspamspam@spam@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 - fastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\20@140550 by Terry

flavicon
face
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.


Terry


At 09:36 AM 12/20/00 -0800, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\20@173328 by Bob Ammerman

picon face
----- Original Message -----
From: Andrew Warren <fastfwdspamspam_OUTIX.NETCOM.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Wednesday, December 20, 2000 12:36 PM
Subject: Re: [EE]: USB stepper drive system


{Quote hidden}

Right.

>     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)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\20@175627 by Andrew Warren

flavicon
face
Bob Ammerman <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> > 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??!??

   Just your basic bulk or interrupt loopback:  4KB out, 4KB in,
   increment a counter on the screen, repeat.

   Windows Me and Win2K are better than Win98... But even on those
   newer OSes, there are still LONG pauses.

   -Andy


=== Andrew Warren --- spamBeGoneaiwspamBeGonespamcypress.com
=== Staff Systems Engineer, IPD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\12\20@182356 by severson

flavicon
face
>     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



> === Opinions expressed above do not
> === necessarily represent those of
> === Andrew Warren --- TakeThisOuTaiwEraseMEspamspam_OUTcypress.com

THAT was easy to re-arrange...  ;-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



'[EE]: USB stepper drive system'
2001\01\01@181114 by Antonio L Benci
flavicon
picon face
part 1 1476 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

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.

Rob Severson wrote:
{Quote hidden}

Nino
--
------------------------------------------------------
| Antonio (Nino) L. Benci                            |
| Professional Officer / Electronic Services Manager |
| School of Physics & Materials Engineering          |
| Monash University                                  |
| T: 61 3 9905 3649. F: 61 3 9905 3637               |
| M: 0414 924 833                                    |
------------------------------------------------------


part 2 566 bytes content-type:text/x-vcard; name=Nino.Benci.vcf; charset=us-ascii
(decoded 7bit)

begin:vcard
n:Benci;Antonio L
tel;cell:0414 924 833
tel;fax:+61 3 9905 3637
tel;home:0414 924 833
tel;work:+61 3 9905 3649
x-mozilla-html:FALSE
url:http://www.physics.monash.edu.au/~ninob
org:Monash University;School of Physics & Materials Engineering
version:2.1
email;internet:RemoveMENino.BencispamTakeThisOuTsci.monash.edu.au
title:Professional Officer/Electronic Services Manager
adr;quoted-printable:;;PO Box 27=0D=0ADepartment of Physics=0D=0AMonash University;Monash University;VIC;3800;Australia
x-mozilla-cpt:;13024
fn:Antonio L Benci
end:vcard


part 3 105 bytes
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2001\01\02@025622 by Roman Black

flavicon
face
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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@165300 by Antonio L Benci

flavicon
picon face
part 1 1693 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

We have several solutions...

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...

> -Roman
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Nino.
--
------------------------------------------------------
| Antonio (Nino) L. Benci                            |
| Professional Officer / Electronic Services Manager |
| School of Physics & Materials Engineering          |
| Monash University                                  |
| T: 61 3 9905 3649. F: 61 3 9905 3637               |
| M: 0414 924 833                                    |
------------------------------------------------------


part 2 588 bytes content-type:text/x-vcard; charset=us-ascii; name=Nino.Benci.vcf
(decoded 7bit)

begin:vcard
n:Benci;Antonio L
tel;cell:0414 924 833
tel;fax:+61 3 9905 3637
tel;home:0414 924 833
tel;work:+61 3 9905 3649
x-mozilla-html:FALSE
url:http://www.physics.monash.edu.au/~ninob
org:Monash University;School of Physics & Materials Engineering
version:2.1
email;internet:EraseMENino.Bencispamsci.monash.edu.au
title:Professional Officer/Electronic Services Manager
adr;quoted-printable:;;PO Box 27=0D=0ASchool of Physics and Materials Engineering=0D=0AMonash University;Monash University;VIC;3800;Australia
x-mozilla-cpt:;26720
fn:Antonio L Benci
end:vcard


part 3 154 bytes
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\03@003331 by Roman Black

flavicon
face
Antonio L Benci wrote:

> 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?
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@005649 by Antonio L Benci

flavicon
picon face
part 1 1317 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

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.

>
> > 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?

Never really tried...

> -Roman
>

Nino.
------------------------------------------------------
| Antonio (Nino) L. Benci                            |
| Professional Officer / Electronic Services Manager |
| School of Physics & Materials Engineering          |
| Monash University                                  |
| T: 61 3 9905 3649. F: 61 3 9905 3637               |
| M: 0414 924 833                                    |
------------------------------------------------------


part 2 588 bytes content-type:text/x-vcard; name=Nino.Benci.vcf; charset=us-ascii
(decoded 7bit)

begin:vcard
n:Benci;Antonio L
tel;cell:0414 924 833
tel;fax:+61 3 9905 3637
tel;home:0414 924 833
tel;work:+61 3 9905 3649
x-mozilla-html:FALSE
url:http://www.physics.monash.edu.au/~ninob
org:Monash University;School of Physics & Materials Engineering
version:2.1
email;internet:RemoveMENino.BenciEraseMEspamEraseMEsci.monash.edu.au
title:Professional Officer/Electronic Services Manager
adr;quoted-printable:;;PO Box 27=0D=0ASchool of Physics and Materials Engineering=0D=0AMonash University;Monash University;VIC;3800;Australia
x-mozilla-cpt:;26720
fn:Antonio L Benci
end:vcard


part 3 144 bytes
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@104459 by Bob Ammerman

picon face
----- Original Message -----
From: Antonio L Benci <RemoveMENino.Bencispam_OUTspamKILLspamSCI.MONASH.EDU.AU>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Wednesday, January 03, 2001 12:50 AM
Subject: Re: [EE]: USB stepper drive system


{Quote hidden}

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)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\01\03@162413 by Olin Lathrop

face picon face
> > 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.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspamspamspamBeGoneembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...