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

Hi Les,

Thanks for the additional information. Sounds like the Mach driver does a
good job, as long as the competing programs you describe are kept out.

I can see how a circular buffer would be used for communication with the
driver. I gather that it passes blocks (structures) of velocity (or steps?)
and step counts for the driver to generate? Are there any return messages?

Any thought to running this circular queue out a USB, and into a hardware
pulse generator device (G2002 comes to mind)?

Alan KM6VV

> -----Original Message-----
> From: CAD_CAM_EDM_DRO@yahoogroups.com
> [mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of Les Newell
> Sent: Monday, July 25, 2005 2:25 AM
> To: CAD_CAM_EDM_DRO@yahoogroups.com
> Subject: Re: [CAD_CAM_EDM_DRO] Windows timing subroutines, how do they
> work?
>
> Hi Alan,
>
> The Mach2/3 driver is not a normal windows task. It installs itself as
> an interrupt handler for the timer then reprograms the interrupt
> controller to make the timer the highest priority. The task scheduler is
> also interrupt driven but as it is now at a lower priority the Mach2
> driver will be serviced before the task scheduler. The driver is then
> fed from the main Mach2 application which runs as a normal high priority
> Windows task. The application communicates with the driver through a
> circular buffer. Each entry in the buffer is the equivalent to one cycle
> of EMC's servo loop. EMC works out the velocities in real time every x
> milliseconds while Mach2 calculates them in advance. The buffer is
> continually filled from Mach2 and emptied by the driver. There are a few
> weaknesses in this arrangement:
>
> DMA or any hardware that disables the CPU will of course interrupt the
> pulses. This is the case with any software based pulser including EMC.
> Some applications and services such as qttask reprogram the timer and/or
> interrupt controller causing the driver to run slow or end up running at
> a lower priority.
> If the system is heavily loaded and Mach2 does not keep the circular
> buffer full the pulses will abruptly halt until Mach2 catches up then
> they will abruptly start up again. Using a bigger circular buffer helps
> but slows down jogging/pause response. This is why response can become
> very choppy for slow CPUs. It doesn't help that the driver is taking up
> a fair percentage of CPU time.
>
> Les
>
>
> KM6VV wrote:
>
> >Hi Les,
> >
> >Interrupt priority? That's it? But isn't it more like the highest TASK
> >priority? the pulse stream could still be delayed or altered if another
> >task was still "taking it's good sweat time", and not relinquishing
> >Control. Do you have more detail?
> >
> >Alan KM6VV
> >
> >