"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"Bob La Londe" fired this volley in
:

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.

When a machine-lanquage 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.

Thanks Llyod, I have gotten pretty good results out of my CNC mills for
making molds. The very last thing I do is spot the plates for the alignment
pins and clamping screws. Mostly they line up. (GRIN) I use hardware LPT
ports on Windows machines, and I like I said I have run over a million lines
of code now in one code file. I've figured out what speeds work. I only
run one primary application at a time. I disable everything in Windows its
possible to disable. I start Mach with a batch file that assigns a higher
than normal priority to Mach, and I turn off the tool path display to reduce
graphic adaptor load when cutting larger files. It works. I don't see why
it would not work for cutting threads with some care. I've got a single
point milling adaptor for thread cutting (basically a boring bar style). If
I can cut loose threads by single point milling I don't see why I couldn't
cut tighter fit threads using a lathe style operation. If absolute
repeatability was required than add a zero switch to the 4th axis (on a
mill) or the head stock (on a lathe) and write a macro to re-zero before
each pass.

Not arguing at all. Just saying what has worked for me.

AND I ABSOLUTELY DO NOT SWAP ANY USB DEVICES WHILE MACH IS CUTTING A FILE.
The only reason I leave USB enabled at all is that thumb drives are the best
way to sneaker net files from my design computer.