On Tue, 19 Jul 2011 09:44:17 -0700, "Bob La Londe"
wrote:

"Gunner Asch" wrote in message
.. .
On Mon, 18 Jul 2011 20:16:33 -0700, "Bob La Londe"
wrote:

"Gunner Asch" wrote in message
news On Mon, 18 Jul 2011 18:13:58 -0700, "Bob La Londe"
wrote:


USB to just about any sort of output..serial, parallel etc etc are
commonly available at any computer shop

LOL. Yeah right. Try running a stepper driver off of one.

I have a number of USB adapters that have an external power supply..so
the power needs are NOT taken from the computers USB port.

Want some links?

I want some links to some that will reliably control 3 or 4 axis of
steppers
for a million lines of code, and probably a several billion signals, and
will work with just about any step direction driver.

I think you totally missed (or chose to miss) that a cheap generic USB
parallel adaptor will not fill the need.


So USB 3.0 isnt fast enough?

Well, I'm not sure its strictly a matter of speed. It's a matter of timing.
I know plenty of people have tried adaptors with poor results. With an
"adaptor" the PC is still doing all the work and then the USB port is
"translating" it. The software would really prefer to control hardware
directly. I can ask over at the Mach Support forum if anybody has better
results with USB 3.0 adaptors, but realistically I can't see how. The
fundamental problem is the same. The SS takes a whole different approach.

Let me know if the subject comes up. Ive got 3 Omniturn lathes in my
stock and was pondering about setting one up under Mach3

Gunner

--
Maxim 12: A soft answer turneth away wrath.
Once wrath is looking the other way, shoot it in the head.

"Gunner Asch" wrote in message
...
On Tue, 19 Jul 2011 09:44:17 -0700, "Bob La Londe"
wrote:

"Gunner Asch" wrote in message
. ..
On Mon, 18 Jul 2011 20:16:33 -0700, "Bob La Londe"
wrote:

"Gunner Asch" wrote in message
news On Mon, 18 Jul 2011 18:13:58 -0700, "Bob La Londe"
wrote:


USB to just about any sort of output..serial, parallel etc etc are
commonly available at any computer shop

LOL. Yeah right. Try running a stepper driver off of one.

I have a number of USB adapters that have an external power supply..so
the power needs are NOT taken from the computers USB port.

Want some links?

I want some links to some that will reliably control 3 or 4 axis of
steppers
for a million lines of code, and probably a several billion signals, and
will work with just about any step direction driver.

I think you totally missed (or chose to miss) that a cheap generic USB
parallel adaptor will not fill the need.


So USB 3.0 isnt fast enough?

Well, I'm not sure its strictly a matter of speed. It's a matter of
timing.
I know plenty of people have tried adaptors with poor results. With an
"adaptor" the PC is still doing all the work and then the USB port is
"translating" it. The software would really prefer to control hardware
directly. I can ask over at the Mach Support forum if anybody has better
results with USB 3.0 adaptors, but realistically I can't see how. The
fundamental problem is the same. The SS takes a whole different approach.

Let me know if the subject comes up. Ive got 3 Omniturn lathes in my
stock and was pondering about setting one up under Mach3


Now that I think about it. No I don't see it working with any generic USB
adaptor. Mach 3 wants the base address for the parallel port or ports. (It
will support 2 for upto 6 axis control with all the appropriate inputs and
outputs.) With a Smoothstepper they load a driver to intermediate or
redirect. No reason you can't use Mach 3 though even if you don't have an
LPT port. CNA has PCI parallel cards for $20. I have two of them in use.
Or of course go with the greater expense of the Smooth Stepper between the
PC and the drivers.

On Tue, 19 Jul 2011 11:47:44 -0700, Gunner Asch
wrote:
snip
Let me know if the subject comes up. Ive got 3 Omniturn lathes in my
stock and was pondering about setting one up under Mach3
snip
===============
From other posts I thought you were running Linux on some of
your computers. Why not download EMC and see if that will
work? Price is right...

http://wiki.linuxcnc.org/emcinfo.pl?Installing_EMC2
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl

http://www.dynomotion.com/Help/GCode...ok/node14.html

http://www.yty.net/cnc/bdi.html

I don't know it this is the same EMC, but this site claims
it runs under windows.
http://softwaretopic.informer.com/micros-emc-download/

"F. George McDuffee" wrote in message
...
On Tue, 19 Jul 2011 11:47:44 -0700, Gunner Asch
wrote:
snip
Let me know if the subject comes up. Ive got 3 Omniturn lathes in my
stock and was pondering about setting one up under Mach3
snip
===============
From other posts I thought you were running Linux on some of
your computers. Why not download EMC and see if that will
work? Price is right...

http://wiki.linuxcnc.org/emcinfo.pl?Installing_EMC2
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl

http://www.dynomotion.com/Help/GCode...ok/node14.html

http://www.yty.net/cnc/bdi.html

I don't know it this is the same EMC, but this site claims
it runs under windows.
http://softwaretopic.informer.com/micros-emc-download/


You can download and install Ubuntu Linux and EMC 2 and burn an installable
CD that will install both on a computer. I used it for a little while. If
its already got Windows on it you can even tell it to set it up for dual
boot at install time. I keep meaning to get back to EMC2, but Mach was a
lot easier (for me) to setup.

On Tue, 19 Jul 2011 12:08:48 -0500, Lloyd E. Sponenburgh wrote:
"Bob La Londe" [wrote]

There is also something to the way resources are allocated for USB as
opposed to a dedicated hardware communication port. I'll leave that to
the guys who know more about specifically USB to explain if they like.
I know if I send a signal to a pin on a hardware LPT port it (barring
the speed of electrons down wire) its virtually delivered precisely
when its sent.

It has to do with the fact that USB resources are controlled from the
Windows kernel drivers. The windows kernel is not a real-time system.
It "queues" operations for completion, then goes off and does other
things while those queued tasks get done on a "when I can, IF I can"
basis.

That may be, but more importantly, USB -- being a serial protocol --
packetizes its messages at the hardware level, and software can do
little or nothing about it. USB hardware supports four kinds of
messages or transfers, none of which are entirely proper for
emulating a real-time LPT port.

(1) For example, although the shortest Control Messages may take as few
as 16 bytes to complete (two 8-byte packets for Setup Stage and Status
Stage), most USB control messages entail a handshake and a Data Stage,
so several times that many bytes get sent back and forth. (See
http://www.beyondlogic.org/usbnutshell/usb4.shtml)

(2) So-called "Interrupt Transfers" from device are "queued by the
device until the host polls the USB device asking for data."
To-device Interrupt Transfers can happen without buffering and
queueing, but still entail three packets (Token, Data, and Handshake
packets) and still can be delayed by buffering at device and by device's
packet validation step.

(3) After being set up, Isochronous Transfers are fast one-way transfers
with bounded latency and no guarantee of delivery, ie fast enough for
real-time control but not ok for reliable interactive control.

(4) Bulk Transfers likewise are unidirectional and fast but have no
guarantee of bandwidth or minimum latency.

The page http://opensourcebridge.org/proposals/40 comments: "Ever get
an urge to control a robot using real time Linux and a serial port, but
find that your computer only has USB ports? [...] Sure, youve been told
that USB is broken for real time at the specification level, but that
wont stop you from trying!"

When a machine-language component of software talks directly to a
hardware device (barring getting pre-empted by interrupt service
routines) the physical task occurs immediately. When a program talks to
the kernal routines instead of directly to the hardware, queued tasks
can take microseconds to _minutes_ to get executed on the hardware.
This is worsened by the fact that many USB peripherals themselves queue
operations, separate and apart from the kernel queuing.

That's why the EMC guys talk about using a "non-preemtive, real-time
kernel" in Linux to run machine control routines.

With the right kernel AND the right USB hardware, USB peripherals _can_
be used in real-time. You just have to pick devices that don't have
their own non-real-time queuing on-board. And if you have to use a
Microsoft product, don't use Windows -- use DOS. But, then, that's not
a very pretty scenario, either.

See http://www.freedos.org/freedos/news/technote/195.html re driver
problems with DOS.

--
jiw