On Wed, Sep 24, 2008 at 8:00 AM, thomas.schoenfelder
<thomas.schoenfelder@...> wrote:
> --- In dwp@yahoogroups.com, "code suidae" <codesuidae@...> wrote:
>>
>> On Tue, Aug 19, 2008 at 6:32 AM, thomas.schoenfelder
>> <thomas.schoenfelder@...> wrote:
>> > --- In dwp@yahoogroups.com, "Joe da Silva" <Joe.daSilva@> wrote:
>> >> Just as DWPL aims to provide a common RAD solution for
>> >> Windoze and DOS, the Lazarus project aims to provide a
>> >> common RAD solution for Windoze and *nix :
>> >
>> > Will it be graphical in DOS too? What about fpGUI library? it is
>> > written system independant. So you can make it working for DOS.
>> > See fpGUI sources. Thre is a implementation layer for several
> platforms.
>>
>> Last I heard the FreePascal stuff for DOS was fairly buggy, mostly due
>> to lack of users. I was interested in using it as the basis of a CNC
>> machine controller (port of TurboCNC), but the prospect of bugs in the
>> tools and not much support turned me off of using it.
>>
> Why DOS at all? Why not Windows console, if you needn't any gui?

Background:

Many inexpensive step-direction CNC controllers are driven directly
from the parallel port. This requires precise timing for good
performance. My mill used 20 tpi screws, 200 step/rev motors and
drivers with 8 microsteps per motor step. In order to rapid move at 70
inches per minute (not unreasonable for a medium sized machine, and
quite comfortable on my desktop machine) this required 32,000 steps
per second, or one step every 31 microseconds. Jitter in the timing
precision more than a small handful of microseconds (say, +/- 4uS) can
cause the motor to lose steps or even stall, resulting in ruined
parts.

Since Windows is not a real-time system, user-mode thread scheduling
cannot guarantee code execution to this sort of precision for any
length of time. It can take hours to cut some parts, and the timing
precision has to maintained for the entire time.

The problem can be mitigated to some extent through the use of
kernel-mode drivers, such as used by the Mach3 software by ArtSoft (a
great product!) It can also be circumvented by using a system with
real-time capabilities, such as RTLinux, or a very simple OS that
pretty much just stays out of the way, like DOS.

The problem is that writing good kernel-mode drivers for Windows
requires tools and knowledge that the sort of people who buy
inexpensive step-direction controllers typically don't have access to.

> Why not a GUI for interaction between user and CNC-control.

That is often preferred, but honestly it doesn't make a whole heck of
a lot of difference in a commercial setting. Text-based UI's are just
as capable of producing a push-the-button-and-make-it-go experience as
is windows.

> A todays
> computer has so much resources, that it can provide a graphical
> frontend for the user.

It is less about how much resource is available and more about /when/
it is available. Windows just doesn't always schedule your code to run
during the right microseconds.

When you get into spending more money on equipment you can offload the
precision timing to hardware designed for it, such as GeckoDrive's
G-Rex product, which can be instructed by the computer at it's
leisure, leaving the computer to provide a nice user interface (and,
more importantly, modern development tools!). In fact, the G-Rex can
be disconnected from the computer and left to run the instructions
provided by the computer after a button press. A useful mode for some
aspects of commercial operations.

> In your case i think, the user will be the
> worker on the CNC machine. Why he should learn cryptical command line
> options instead of clicking some buttons with his needed commands,
> fired by clicking the buttons.

Typically DOS-based CNC systems are windowing, menu driven systems
implemented in text (though graphics is not out of the question, it's
just a lot more work for the programmer because the DOS tools are
generally much more primitive).

You can see an example of this in the DOS part of a system I wrote using DWP:

http://davestech.blogspot.com/2007/10/gcode-scripting.html

It's the last image at the bottom of the page.

CS
--
"Our ignorance is not so vast as our failure to use what we know." -
M. King Hubbert