Re: Windows timing subroutines, how do they work?

In my opinion it should not be the task of a PC to do the 'donkey
work' of generating step pulses be it Linux, DOS or Windows. That is
a task that belongs to dumb dedicated hardware.

A PC is an 'intelligence engine'. It's task is to do a lot of math
and make decisions. Its output product should go to a 'pulse engine',
hardware finely tuned to the task of generating of producing pure and
clean frequencies on demand from the PC.

These are tasks are so diametrically opposed it's like using a claw
hammer for a screwdriver. In a pinch you can do it but it's not
pretty.

That also pretty much surmises what I have seen from most PC based
CNC programs. The step pulse phase jitter is horrible even from the
most popular out there. The motors sound like a barrel of agitated
monkeys and I have the scope pixs to prove it.

If things are going to be done right, the PC has to interface to some
kind of step pulse engine.

The 'agitated monkey' part. Motors that sound like that are being
robbed of their potential torque especially at high speeds. Phase
modulation imposes unnecessary torque demands (infinite impulse
functions) on the motors. Said more simply, you pay for all that
noise in performance.

Mariss

--- In CAD_CAM_EDM_DRO@yahoogroups.com, Jon Elson <elson@p...> wrote:
> 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