RE: [CAD_CAM_EDM_DRO] Windows timing subroutines, how do they work?

No I think over analyzed my post.

-----Original Message-----
From: CAD_CAM_EDM_DRO@yahoogroups.com
[mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of Jon Elson
Sent: Sunday, July 24, 2005 10:01 PM
To: CAD_CAM_EDM_DRO@yahoogroups.com
Subject: Re: [CAD_CAM_EDM_DRO] Windows timing subroutines, how do they work?

Jack Hudler wrote:

>Turn off multitasking: NO. You could try elevating your process to realtime
>status, but I can tell you it probably will not fix your issue. Doing so
>would probably make the user experience unpalatable.
>
>You're trying to do realtime work on an operating system that isn't

designed

>for realtime work (Linux or Windows). Even if you use a special realtime
>build you just run into CPU bandwidth issues with your requirements and the
>requirements of other devices (clock, comports, disk, mouse, display,

sound,

>dma, pci, usb, etc). There are other interrupts and processes that require
>service and the OS has no idea that doing so will crash your machine tool.
>
>

So, you are saying that EMC (using a real-time Linux) simply has never
worked, and
perfoms unpredictably? The way they fixed this is to make the real time
extension
to Linux able to pre-empt the kernel, and all of its tasks. The
interrupt latency
is around 5 uS on a 100 MHz pentium classic, and vastly faster on newer
hardware.
The jitter in the regularly scheduled interrupts is under 1 uS! And,
that is an absolute,
not some statistical average. It NEVER stutters by more than 1 uS,
EVER, no matter
how long you sample for.

>
>

I've been running a servo Bridgeport mill since 1998 using EMC under
real-time Linux,
and I can tell you with great authority that the timing is not corrupted
by "clock, comports,
disk, mouse, display, sound,dma, pci, usb, etc."

Jon