Digital Mars - c++ - Windows response time and advices

↑ ↓ ← → Roland <rv ronetech.com> writes:

One of our program is a DOSX program.

We make real time with it on pure Dos: drives a cnc machine tool.

It works fine, and i think nothing is faster than DOSX associated with
DM C++.

but i have some worries for the future:

1- will we be able to run in pure DOS mode in the future ? (i think Win
2000 and Win Me as well don't support pure
dos mode),

2- PC's hardware are less and less PC Compatible.. as hardware is more
and more virtualized,

3- for network, scanner and web cam, we have to restart windows, witch
is pretty long..

We are studying different solution for the future.

One is to put more hardware in the machine (buffer) and port our program
on Windows.

The question is:

What is the maximum response time of windows on hardware request ?

There is already some real time program on windows:

software audio and image decompression, web cam, CD-R engraving, etc...

I would like to have some general informations about those kind of
software, do i have to make a device driver, is there someting
special to know, advices, etc..

Thanks very much

Roland

May 23 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

There will always be PC-104 and it will always run DOS.  PC-104 is an ISA bus
PC architecture having a different mechanical form factor which is tailored for
embedded applications.  PC-104+ is 
the PCI version of same.  Both should be around a good long time.  Check into
it.

http://www.pc104.org/

Mark


On Thu, 24 May 2001 10:37:02 +0200, NancyEtRoland <nancyetroland free.fr> wrote:
 well, we will sell 20 of our micro machine tools on 2001 and 50 on 2002, each
 one
 networked with one or two pc's..
 
 regards
 
 rolland
 
 Walter a �crit :
 
 Why not just stick with vanilla DOS? If it solves the problem, there's no
 need to upgrade. After all, for running a machine tool, what does Windows
 2000 offer?

 If the future is a concern, buy a few backup computers that will run DOS,
 and save copies of your DOS disks in a safe place.

  -Walter

May 24 2001

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

Cool!
I didn't know they were that serious about it!

Jan



Mark Evans wrote:

 There will always be PC-104 and it will always run DOS.  PC-104 is an ISA bus
PC architecture having a different mechanical form factor which is tailored for
embedded applications.  PC-104+ is
 the PCI version of same.  Both should be around a good long time.  Check into
it.

 http://www.pc104.org/

 Mark

 On Thu, 24 May 2001 10:37:02 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 well, we will sell 20 of our micro machine tools on 2001 and 50 on 2002, each
 one
 networked with one or two pc's..

 regards

 rolland

 Walter a �crit :

 Why not just stick with vanilla DOS? If it solves the problem, there's no
 need to upgrade. After all, for running a machine tool, what does Windows
 2000 offer?

 If the future is a concern, buy a few backup computers that will run DOS,
 and save copies of your DOS disks in a safe place.

  -Walter

May 24 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

Yeah, they are sweet.  However I consider DOS ugly, something that should have
died a long time ago, especially for embedded apps.

My hope is that Real-Time Linux will get to a point of stability such that it
displaces all the old DOS stuff in the embedded world.  RT Linux will run on
PC-104 too.  You have to realize that PC-
104 is the same PC as sits on your desk except for the mechanical aspects.

For those interested in a Windows-compliant embedded tool check out Real Time
Target (RTT) out of Germany which is a Win API emulation for real-time targets.
 You end up writing code 
that pretty much reads, walks, and quacks like Windows or DOS code, but which
actually runs on a real-time kernel.  It will even call DLLs.

Still it's great that Digital Mars supports 16-bit code and the DOS extended
stuff.  Very few compilers still do.

Mark


On Thu, 24 May 2001 12:26:22 -0400, Jan Knepper <jan smartsoft.cc> wrote:
 Cool!
 I didn't know they were that serious about it!
 
 Jan
 
 
 
 Mark Evans wrote:
 
 There will always be PC-104 and it will always run DOS.  PC-104 is an ISA bus
PC architecture having a different mechanical form factor which is tailored for
embedded applications.  PC-




 the PCI version of same.  Both should be around a good long time.  Check into
it.

 http://www.pc104.org/

 Mark

 On Thu, 24 May 2001 10:37:02 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 well, we will sell 20 of our micro machine tools on 2001 and 50 on 2002, each
 one
 networked with one or two pc's..

 regards

 rolland

 Walter a �crit :

 Why not just stick with vanilla DOS? If it solves the problem, there's no
 need to upgrade. After all, for running a machine tool, what does Windows
 2000 offer?

 If the future is a concern, buy a few backup computers that will run DOS,
 and save copies of your DOS disks in a safe place.

  -Walter

May 24 2001

↑ ↓ ← → NancyEtRoland <nancyetroland free.fr> writes:

Mark Evans a �crit :

 Yeah, they are sweet.  However I consider DOS ugly, something that should have
died a long time ago, especially for embedded apps.


in fact there is nothing in DOS, you have to do everything, you controle
everything.

 My hope is that Real-Time Linux will get to a point of stability such that it
displaces all the old DOS stuff in the embedded world.  RT Linux will run on
PC-104 too.


Linux is one option we are studying,

 For those interested in a Windows-compliant embedded tool check out Real Time
Target (RTT) out of Germany which is a Win API emulation for real-time targets.
 You end up writing code
 that pretty much reads, walks, and quacks like Windows or DOS code, but which
actually runs on a real-time kernel.  It will even call DLLs.


interesting,


 Still it's great that Digital Mars supports 16-bit code and the DOS extended
stuff.  Very few compilers still do.


and 32 bit DOSX too !


Roland

May 25 2001

↑ ↓ ← → NancyEtRoland <nancyetroland free.fr> writes:

Thanks

well some years ago we used industrial pc board.

the problem is
1- only the board is the price of a complete pc,
2- pc-104 is ISA isn't it ?

now we put the complete pc inside an industrial box

regard

Mark Evans a �crit :

 There will always be PC-104 and it will always run DOS.  PC-104 is an ISA bus
PC architecture having a different mechanical form factor which is tailored for
embedded applications.  PC-104+ is
 the PCI version of same.  Both should be around a good long time.  Check into
it.

 http://www.pc104.org/

 Mark

 On Thu, 24 May 2001 10:37:02 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 well, we will sell 20 of our micro machine tools on 2001 and 50 on 2002, each
 one
 networked with one or two pc's..

 regards

 rolland

 Walter a �crit :

 Why not just stick with vanilla DOS? If it solves the problem, there's no
 need to upgrade. After all, for running a machine tool, what does Windows
 2000 offer?

 If the future is a concern, buy a few backup computers that will run DOS,
 and save copies of your DOS disks in a safe place.

  -Walter

May 25 2001

↑ ↓ ← → NancyEtRoland <nancyetroland free.fr> writes:

NancyEtRoland a �crit :

 2- pc-104 is ISA isn't it ?


i should read your messages more carefully ..

Thanks again

 Mark Evans a �crit :

 There will always be PC-104 and it will always run DOS.  PC-104 is an ISA bus
PC architecture having a different mechanical form factor which is tailored for
embedded applications.  PC-104+ is
 the PCI version of same.  Both should be around a good long time.  Check into
it.

 http://www.pc104.org/

 Mark

May 25 2001

↑ ↓ ← → NancyEtRoland <nancyetroland free.fr> writes:

first i esitate to expose my problem here as it is not specificaly DM C++.

but i would like it to have a DM C++ based solution..

More informations:

a PC based little cnc machine:

- must run a real time softwear,
- must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
a web cam is plugged on it, it is plugged on Internet  for remote mantenance
(Symantec pcAnywhere), etc..

well i don't feel like making all those drivers on MS-DOS..

The actual solution is:

A windows CAD/CAM program on the cnc and on the pc networked with it,
a DOSX program only on the cnc, for driving the cnc itself on real time mode
on pure dos.

The problems are:

- i wrote my worries about the future of DOS but especially the fact that pc
motherboard are less and less pc compatible, (yes pc-104 is a solution)
- i'm afraid pure dos mode will not exist any more on windows,
- switching from windows to pure dos and back is long,
- two programs to mantain.

The ideal solution would be to integrate the DOSX real time program inside
the Windows CAD/CAM program.

I think Linux can be a solution.
I think Windows can do it two.

We have a Windows programmer but he is not a system programmer,
i'm rather system programing oriented, but not a Windows programmer.

that is the reason i asked for help for system programming on Windows

Thanks

Roland


Roland a �crit :

 One of our program is a DOSX program.

 We make real time with it on pure Dos: drives a cnc machine tool.

 It works fine, and i think nothing is faster than DOSX associated with
 DM C++.

 but i have some worries for the future:

 1- will we be able to run in pure DOS mode in the future ? (i think Win
 2000 and Win Me as well don't support pure
 dos mode),

 2- PC's hardware are less and less PC Compatible.. as hardware is more
 and more virtualized,

 3- for network, scanner and web cam, we have to restart windows, witch
 is pretty long..

 We are studying different solution for the future.

 One is to put more hardware in the machine (buffer) and port our program
 on Windows.

 The question is:

 What is the maximum response time of windows on hardware request ?

 There is already some real time program on windows:

 software audio and image decompression, web cam, CD-R engraving, etc...

 I would like to have some general informations about those kind of
 software, do i have to make a device driver, is there someting
 special to know, advices, etc..

 Thanks very much

 Roland

May 25 2001

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

Roland,

You might want to look into writing a Windows NT device driver for this.
I have no idea what the required response times are your program needs.
If you want to get something working I would suggest, try a "service" on Windows
NT/2000 first. If that is reliable enough you're done easy. If not, you might
want to put the code into a device driver and see if that will work.
The problem with Windows NT/2000 is that everything seems to run in kernel mode
as the Unix people call it. Unix has split off the operating system which runs
in level-0 while userland is in level-1. This way the operating system can
always repond as it controls the system. I think that most (if not everyone) of
the people on this newgroup know that:

while ( 1 )
    ;

Has a rather great effect on Windows NT/2000. Start a number of threads with
these kind of things and you probably won't be able anymore to decently shutdown
the system.

Anyways, for information on how to write a Windows NT/2000 device driver check
http://www.osr.com/., Patrick van Hoorn Alkema (PvHA compuserve.com), who also
used to use Symantec C++ and may be still does, forwarded me to this site and
the book they sell has been of great help to me.

If it were not that I am swamped with work already I would offer you to help to
convert the current program to a Windows NT/2000 service, but I can not decently
offer that right now.

Don't worry, be Kneppie!
Jan



NancyEtRoland wrote:

 I think Windows can do it two.

 We have a Windows programmer but he is not a system programmer,
 i'm rather system programing oriented, but not a Windows programmer.

 that is the reason i asked for help for system programming on Windows

May 26 2001

↑ ↓ ← → "Patrick vHAlkema" <pvha compuserve.com> writes:

... Patrick van Hoorn Alkema (PvHA compuserve.com), who also





Certainly do!

I'd be glad to help with advice if 'NancyEtRoland' would contact me - I've
written a lot of services, but no NT device drivers, though I have been on a
course from OSR on the subject, and have written VMS device drivers (very
similar).

Like you, I've been a bit busy, and don't check out the DigitalMars stuff as
often as I should.

The problem with Windows NT/2000 is that everything seems to run in kernel




as the Unix people call it. Unix has split off the operating system which
runs
in level-0 while userland is in level-1. This way the operating system can
always repond as it controls the system. I think that most (if not everyone)
of
the people on this newgroup know that:

while ( 1 )
    ;

Has a rather great effect on Windows NT/2000.<<

IMHO NOT TRUE: only WIN32 API's (and not all of them) and device drivers run
in kernel mode. User code runs in user mode just as in UNIX and other O/S's.
The difference is that NT/2000 CPU- and Memory-scheduler is by-default
biased toward code run by the logged-in user (to deliver snappy response),
so a user program that hogs CPU cycles will have a serious effect - it
should do the equivalent of 'nice' first, and that will adjust it's quotas
to allow other stuff to run properly.

The NT CPU scheduler is very powerful and flexible, it's just that no-one
uses it properly - everyone runs with default priority regardless of what
they are doing! You can run a program with altered priority quite easily,
either run it from a command window with 'START /<priority>  FRED.EXE' (see
'HELP START | MORE' in command window) or adjust the priority while running
using the Task Manager (processes tab, right-click on the process in
question and select priority). In this case, it sounds like 'realtime'
priority would be useful - a process with this priority will pre-empt any
other process in the system as soon as it becomes runnable, so should not do
any lengthy computing. For the record, if you do port a program to NT, you
can make it multi-threaded and assign a separate piority to each thread (you
have to do this in code), so make one thread deal with real-time stuff at
realtime priority, and another thread run at default or lower priority to do
the housekeeping, display updating whatever.

For the record, the characteristics of an NT service can be summarised as
follows:

a) Written and built as a 'standard' console-mode NT program, but console
input and output routed to NUL during execution.

b) 'main' entrypoint calls a special WIN32 API 'StartServiceCtrlDispatcher'
with a pointer to address of a routine that does the processing for your
program. This routine is run in a separate thread - the main thread stays in
communication with the service control manager, essentially asleep.

c) Needs to be installed prior to use.

d) Only one instance of each service can run - multiple instances (if
needed) must be installed with unique names.

e) (usually) runs in a 'local-system' account with admin privileges but NO
NETWORK ACCESS - at least no ability to access network-mounted discs, and no
desktop access (no visible windows). You can run socket (TCP/IP, UDP/IP etc)
code though. EXE file *must* be on local disc.

f) Survives user logout - keeps running when no-one is logged in. Basically
independent of the logged-in user.

g) Can be set to start automatically on bootup.

h) Is no more part of the system than any other program, so it is not
preferentially treated by the memory- or CPU-scheduler. Runs in user mode
like any other program.

i) Very tricky to debug. I build all my services such that 'main' looks for
a special argument or environment variable, and if that is set, don't call
'StartServiceCtrlDispatcher', just run the code routine it would run - that
way you can run the program under the debugger in the user context and see
console (i.e. printf etc) output.

May 28 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

My advice is the following.  If you want true real-time performance with
Windows compatibility, then you need a Windows API emulator that runs on a
real-time kernel.  On-time sells exactly 
that.

		http://www.on-time.com/

Personally I would never bother with Windows for hard real-time requirements.

You might also consider the WINE project with Real-Time Linux, but I am told
that RT Linux is much less mature (more buggy) than Linux per se.

I'm no expert on DOSX but presumably if it runs under DOSX then it will run
under Windows emulation.

Mark



On Sat, 26 May 2001 01:48:30 +0200, NancyEtRoland <nancyetroland free.fr> wrote:
 first i esitate to expose my problem here as it is not specificaly DM C++.
 
 but i would like it to have a DM C++ based solution..
 
 More informations:
 
 a PC based little cnc machine:
 
 - must run a real time softwear,
 - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
 a web cam is plugged on it, it is plugged on Internet  for remote mantenance
 (Symantec pcAnywhere), etc..
 
 well i don't feel like making all those drivers on MS-DOS..
 
 The actual solution is:
 
 A windows CAD/CAM program on the cnc and on the pc networked with it,
 a DOSX program only on the cnc, for driving the cnc itself on real time mode
 on pure dos.

May 28 2001

↑ ↓ ← → Damian Dixon <damian.dixon tenetdefence.com> writes:

I would suggest looking at spliting up your system so that the realtime element
of
the CNC controller runs on a small embedded board.

You will then only need to write a simple windows program to send commands to
the
CNC controller to instruct it how to cut (start position, stop position, speed,
depth
and path). You could probably get away with using RS232 or the printer port for
the comm's.

Regards,
Damian

On Mon, 28 May 2001 22:15:28 GMT, Mark Evans <mevans zyvex.com> wrote:
 
 My advice is the following.  If you want true real-time performance with
Windows compatibility, then you need a Windows API emulator that runs on a
real-time kernel.  On-time sells exactly 
 that.
 
 		http://www.on-time.com/
 
 Personally I would never bother with Windows for hard real-time requirements.
 
 You might also consider the WINE project with Real-Time Linux, but I am told
that RT Linux is much less mature (more buggy) than Linux per se.
 
 I'm no expert on DOSX but presumably if it runs under DOSX then it will run
under Windows emulation.
 
 Mark
 
 
 
 On Sat, 26 May 2001 01:48:30 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 first i esitate to expose my problem here as it is not specificaly DM C++.
 
 but i would like it to have a DM C++ based solution..
 
 More informations:
 
 a PC based little cnc machine:
 
 - must run a real time softwear,
 - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
 a web cam is plugged on it, it is plugged on Internet  for remote mantenance
 (Symantec pcAnywhere), etc..
 
 well i don't feel like making all those drivers on MS-DOS..
 
 The actual solution is:
 
 A windows CAD/CAM program on the cnc and on the pc networked with it,
 a DOSX program only on the cnc, for driving the cnc itself on real time mode
 on pure dos.

May 31 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

Yes

Actually with DOSX we run at 40000 hardware interrups per seconds.

I think i will never go as fast on Windows.

So i need to make some harware (buffer) to help Windows.

But how much ?

The faster i can go on Windows, the cheaper and simpler is the hardware
associated with it.

Thanks

Roland

Damian Dixon a �crit :

 I would suggest looking at spliting up your system so that the realtime
element of
 the CNC controller runs on a small embedded board.

 You will then only need to write a simple windows program to send commands to
the
 CNC controller to instruct it how to cut (start position, stop position,
speed, depth
 and path). You could probably get away with using RS232 or the printer port for
 the comm's.

 Regards,
 Damian

 On Mon, 28 May 2001 22:15:28 GMT, Mark Evans <mevans zyvex.com> wrote:
 My advice is the following.  If you want true real-time performance with
Windows compatibility, then you need a Windows API emulator that runs on a
real-time kernel.  On-time sells exactly
 that.

               http://www.on-time.com/

 Personally I would never bother with Windows for hard real-time requirements.

 You might also consider the WINE project with Real-Time Linux, but I am told
that RT Linux is much less mature (more buggy) than Linux per se.

 I'm no expert on DOSX but presumably if it runs under DOSX then it will run
under Windows emulation.

 Mark



 On Sat, 26 May 2001 01:48:30 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 first i esitate to expose my problem here as it is not specificaly DM C++.

 but i would like it to have a DM C++ based solution..

 More informations:

 a PC based little cnc machine:

 - must run a real time softwear,
 - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
 a web cam is plugged on it, it is plugged on Internet  for remote mantenance
 (Symantec pcAnywhere), etc..

 well i don't feel like making all those drivers on MS-DOS..

 The actual solution is:

 A windows CAD/CAM program on the cnc and on the pc networked with it,
 a DOSX program only on the cnc, for driving the cnc itself on real time mode
 on pure dos.

May 31 2001

↑ ↓ ← → Damian Dixon <damian.dixon tenetdefence.com> writes:

On Thu, 31 May 2001 11:07:13 +0200, Roland <rv ronetech.com> wrote:
 Yes
 
 Actually with DOSX we run at 40000 hardware interrups per seconds.
 
 I think i will never go as fast on Windows.
 


Depends on what the PC-Spec is and what else you are running.

I avoid Windows for real-time applications if at all possible, but my main
reason is uptime of the OS :>

 So i need to make some harware (buffer) to help Windows.
 
 But how much ?


Not knowing exactly how your hardware and software works limits suggestions
that can be made.

I would not suggest buffering the interrupts, but dealing with the interrupts 
on the external controller. Passing only high level commands to and from the
external
controller.

Does the PC control the stepper moters of the CNC machine directly or is there
a 
controller in the CNC already? or do you have an ISA/PCI card sitting in the PC?

A small external 16bit processor board would probably cost between �20 to �100
(pounds) depending on how complex the board is (not taking into acount
development cost of the board and associated software). But this is a big guess
as I
don't know enough about your setup.

If you already have a ISA/PCI card then it may be more sensible to enhance this
card
rather then add an additional external controller.

 
 The faster i can go on Windows, the cheaper and simpler is the hardware
associated with it.
 


Yes. However you may find adding an external controller is cheaper then trying
to get 
your windows program to run fast enough.

As you probably already know if your control program is not fast enough you will
probably lose cutting accuracy.

Hopefully my suggestions have helped you, but as you can see there is a limit
to what I can suggest based on the information you have posted.

Regards
Damian

 Thanks
 
 Roland
 
 Damian Dixon a �crit :
 
 I would suggest looking at spliting up your system so that the realtime
element of
 the CNC controller runs on a small embedded board.

 You will then only need to write a simple windows program to send commands to
the
 CNC controller to instruct it how to cut (start position, stop position,
speed, depth
 and path). You could probably get away with using RS232 or the printer port for
 the comm's.

 Regards,
 Damian

 On Mon, 28 May 2001 22:15:28 GMT, Mark Evans <mevans zyvex.com> wrote:
 My advice is the following.  If you want true real-time performance with
Windows compatibility, then you need a Windows API emulator that runs on a
real-time kernel.  On-time sells exactly
 that.

               http://www.on-time.com/

 Personally I would never bother with Windows for hard real-time requirements.

 You might also consider the WINE project with Real-Time Linux, but I am told
that RT Linux is much less mature (more buggy) than Linux per se.

 I'm no expert on DOSX but presumably if it runs under DOSX then it will run
under Windows emulation.

 Mark



 On Sat, 26 May 2001 01:48:30 +0200, NancyEtRoland <nancyetroland free.fr>
wrote:
 first i esitate to expose my problem here as it is not specificaly DM C++.

 but i would like it to have a DM C++ based solution..

 More informations:

 a PC based little cnc machine:

 - must run a real time softwear,
 - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
 a web cam is plugged on it, it is plugged on Internet  for remote mantenance
 (Symantec pcAnywhere), etc..

 well i don't feel like making all those drivers on MS-DOS..

 The actual solution is:

 A windows CAD/CAM program on the cnc and on the pc networked with it,
 a DOSX program only on the cnc, for driving the cnc itself on real time mode
 on pure dos.

May 31 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

 I avoid Windows for real-time applications if at all possible, but my main
 reason is uptime of the OS :>


sorry, i don't understand "uptime of the OS :>"

you avoid Windows for real-time applications: did you already made some ?

 Does the PC control the stepper moters of the CNC machine directly or is there
a
 controller in the CNC already? or do you have an ISA/PCI card sitting in the
PC?


not only stepper motor, cc motor as well.

the cnc is a software cnc.
there is an external board based on a CPLD, plugged on the ECP Parallel port.
It provides only low level services: io, wired security, some wired logic and
power management.

 (not taking into acount development cost of the board and associated software).


that is the problem, i wonder if it is cheaper than making a Windows device
driver.
the big if is: can a device driver do the job ?

And a PC Motherboard is quite a powerfull and cheap board..

 Yes. However you may find adding an external controller is cheaper then trying
to get
 your windows program to run fast enough.


that is the question.

I just know some windows program/device driver use to make software MPEG or MP3
decompression.

that is real time and quite fast isn't it ?

In fact, i know there is special PC cnc board: see
www.galilmc.com, ni.com
and other.

But we have some 'virtual cnc' classes i hesitate to trow away.

I'm just exploring all the possibilities. I try to evaluate what Windows can do
before taking
a decision.

Thanks and Regards

Roland

Jun 01 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

I think this discussion belongs on some other newsgroup now.  It is asking how
to design a CNC system and that's not what we're here for.

Good luck though.

-- Mark


On Fri, 01 Jun 2001 15:08:46 +0200, Roland <rv ronetech.com> wrote:
 I avoid Windows for real-time applications if at all possible, but my main
 reason is uptime of the OS :>


 sorry, i don't understand "uptime of the OS :>"
 
 you avoid Windows for real-time applications: did you already made some ?
 
 Does the PC control the stepper moters of the CNC machine directly or is there
a
 controller in the CNC already? or do you have an ISA/PCI card sitting in the
PC?


 not only stepper motor, cc motor as well.
 
 the cnc is a software cnc.
 there is an external board based on a CPLD, plugged on the ECP Parallel port.
 It provides only low level services: io, wired security, some wired logic and
power management.
 
 (not taking into acount development cost of the board and associated software).


 that is the problem, i wonder if it is cheaper than making a Windows device
driver.
 the big if is: can a device driver do the job ?
 
 And a PC Motherboard is quite a powerfull and cheap board..
 
 Yes. However you may find adding an external controller is cheaper then trying
to get
 your windows program to run fast enough.


 that is the question.
 
 I just know some windows program/device driver use to make software MPEG or
MP3 decompression.
 
 that is real time and quite fast isn't it ?
 
 In fact, i know there is special PC cnc board: see
 www.galilmc.com, ni.com
 and other.
 
 But we have some 'virtual cnc' classes i hesitate to trow away.
 
 I'm just exploring all the possibilities. I try to evaluate what Windows can
do before taking
 a decision.
 
 Thanks and Regards
 
 Roland

Jun 03 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

Thank you very much everybody,

I'm always surprised how powerful internet is, thank to people like you.

Now i have to "digest" all those information and use some of usefull links you
give me.

Roland


NancyEtRoland a �crit :

 first i esitate to expose my problem here as it is not specificaly DM C++.

 but i would like it to have a DM C++ based solution..

 More informations:

 a PC based little cnc machine:

 - must run a real time softwear,
 - must run a "'evoluted" OS because it is plugged on a LAN with other pc's,
 a web cam is plugged on it, it is plugged on Internet  for remote mantenance
 (Symantec pcAnywhere), etc..

 well i don't feel like making all those drivers on MS-DOS..

 The actual solution is:

 A windows CAD/CAM program on the cnc and on the pc networked with it,
 a DOSX program only on the cnc, for driving the cnc itself on real time mode
 on pure dos.

 The problems are:

 - i wrote my worries about the future of DOS but especially the fact that pc
 motherboard are less and less pc compatible, (yes pc-104 is a solution)
 - i'm afraid pure dos mode will not exist any more on windows,
 - switching from windows to pure dos and back is long,
 - two programs to mantain.

 The ideal solution would be to integrate the DOSX real time program inside
 the Windows CAD/CAM program.

 I think Linux can be a solution.
 I think Windows can do it two.

 We have a Windows programmer but he is not a system programmer,
 i'm rather system programing oriented, but not a Windows programmer.

 that is the reason i asked for help for system programming on Windows

 Thanks

 Roland

 Roland a �crit :

 One of our program is a DOSX program.

 We make real time with it on pure Dos: drives a cnc machine tool.

 It works fine, and i think nothing is faster than DOSX associated with
 DM C++.

 but i have some worries for the future:

 1- will we be able to run in pure DOS mode in the future ? (i think Win
 2000 and Win Me as well don't support pure
 dos mode),

 2- PC's hardware are less and less PC Compatible.. as hardware is more
 and more virtualized,

 3- for network, scanner and web cam, we have to restart windows, witch
 is pretty long..

 We are studying different solution for the future.

 One is to put more hardware in the machine (buffer) and port our program
 on Windows.

 The question is:

 What is the maximum response time of windows on hardware request ?

 There is already some real time program on windows:

 software audio and image decompression, web cam, CD-R engraving, etc...

 I would like to have some general informations about those kind of
 software, do i have to make a device driver, is there someting
 special to know, advices, etc..

 Thanks very much

 Roland

May 31 2001