Re: [CAD_CAM_EDM_DRO] Re: Pulse Gen

In regards to Operating Systems, my thoughts run something along these
lines:
If the PC is Only going to be used for CNC work, perhaps some REALLY GOOD
programers out there could write a "basic" langauage program (using the
original computer machine language command sets) for doing whatever you need
CNC wise. Don't ask me how....I quit writing those kinds of programs way
back in 1975!

At any rate, this would bypass all those interrupt restrictions.

Smoke
-----Original Message-----
From: Jon Elson <jmelson@...>
To: CAD_CAM_EDM_DRO@egroups.com <CAD_CAM_EDM_DRO@egroups.com>
Date: Thursday, December 07, 2000 4:54 PM
Subject: Re: [CAD_CAM_EDM_DRO] Re: Pulse Gen

>
>
>Jeff Barlow wrote:
>
>> Jon,
>>
>> I sent Mariss a message off list in which I tried to explain this same
>> issue. I suspect he is a bit naive when it comes to PC interfacing. The
>> sad truth is that the PC interrupt system is very flaky, even with
>> Linux.
>
>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
>
>
>
>Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the

discussion of shop built systems, for CAD, CAM, EDM, and DRO.

>
>Addresses:
>Post message: CAD_CAM_EDM_DRO@egroups.com
>Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
>Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
>List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
>Moderator: jmelson@... [Moderator]
>URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
>FAQ: http://www.ktmarketing.com/faq.html
>bill,
>List Manager
>
>
>