Re: [CAD_CAM_EDM_DRO] Re: Pulse Gen

Jon,

My short answer to this is that you have been lucky.

These problems are very configuration dependant. What works fine on one
box will crash and burn on another. It varies as a function of
motherboard chip set, I/O card mix, which slots they're plugged into,
BIOS version, what favors the "plug and pray" logic tries to do for you,
and maybe phase of the moon.

Don't start feeling too safe just because you get something to work on a
few systems. Been there, done that.

Jeff

On Thu, 07 Dec 2000 17:59:47 -0600, you wrote:

>
>
>Well, in general, OS's do their own stuff first, then worry about
>servicing I/O interrupts. DOS doesn't have much housekeeping
>to do, so it is not too bad, and you can take over the interrupts,
>anyway. About the only one that really keeps on going is the
>interval timer. Linux, without the RT patch, is much the same.
>
>Linux WITH the RT patch is essentially an embedded system,
>dedicated to the RT process, which allows wasted (idle) time to
>be used by Linux. Interrupt latency is better than 10 uS even on
>fairly slow processors, MAX! If you take that latency into consideration,
>it is a fully-fledged hard real time system. This places a hell of a lot
>of constraints on what the RT process can do - it can't make any
>system calls at all, it is running in real mode, has access to the
>entire machine's memory, etc. But, the RT process has as much of
>the machine as it needs, when it needs it. Period.
>
>If it misses even one interrupt, or takes longer than about 750 uS
>to get around to servicing it, I WILL get an emergency stop on my
>servo system. And, that has never happened, in 2 years, except
>when the GUI locked up and I had to reboot. That did cause the
>estop. (This was an old X-windows problem, corrected in early
>1999.) But, in that case, even though the GUI was dead, and most
>probably Linux, too, the RT process was merrily chugging along,
>doing its work without fail.
>
>Jon
>