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

Les Newell wrote:

>Hi Jon,
>
>
>
>>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.
>>
>>
>>
>>
>Even if doing DMA or heavy accelerated graphics? I find that hard to
>believe. The PC's hardware is simply not designed to achieve that sort
>of timing resolution.
>

Well, I have the ability to measure it with a logic analyzer and
oscilloscope.
At least on some machines, all disk I/O is DMA, on some others it is done
by the CPU. I don't run 3-D games while machining, so there might be some
load associated with texture buffers, etc. that could slow things down on
certain motherboard/video card combinations. But, I certainly have not seen
any sign of jitter above 1 uS in the performance of the servo update task
on recent machines of the 400-600 MHz class.

>
>
>
>>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."
>>
>>
>>
>>
>That isn't a fair example. What is your servo cycle time? I would have
>thought it would be around 1ms. Even timing jitter of 100us is unlikely
>to have a noticeable effect.
>

But I've MEASURED it! I'm not guessing from listening to the motors. And,
a 10% change in servo interval would definitely have a noticable effect,
as the
distance traveled during one cycle would vary by 10%, causing a velocity
compensation of 10% x the servo gain. This would likely cause the velocity
command to jump from zero to 100% every cycle. Although I do run at 1 KHz,
the software is capable of running to at least 10 KHz on modern PCs.

> This is easily achieveable as DMA etc are
>unlikely to continue for more then a few tens of us. I bet that EMC also
>has jitter problems when running steppers, just like Mach2.
>
>

Well, I don't know what level of jitter problems you are talking about.
There is a granularity problem, that step pulses can be put on an interval,
but not between intervals. That interval is limited by CPU speed and the
technique of making the pulses.

>Of course a hardware pulser is the best solution for steppers but it
>adds quite a bit to the cost.
>
>

Well, that is my solution, using my universal stepper controller board
to relieve
the CPU of that task, and it improves the timing of the step pulses by a
factor
of about 160, depending on the CPU speed. Since my board does the work of
several boards (breakout board, SSR mounting panel, emergency controls) it
really doesn't cost very much extra. In general, it roughly doubles the
usable
speed of most stepper systems, primarily by reducing the step granularity.

Jon