c++ - Windows response time and advices
- Roland <rv ronetech.com> May 23 2001
- "Walter" <walter digitalmars.com> May 23 2001
- NancyEtRoland <nancyetroland free.fr> May 24 2001
- Mark Evans <mevans zyvex.com> May 24 2001
- Jan Knepper <jan smartsoft.cc> May 24 2001
- Mark Evans <mevans zyvex.com> May 24 2001
- Jan Knepper <jan smartsoft.cc> May 24 2001
- Jan Knepper <jan smartsoft.cc> May 24 2001
- NancyEtRoland <nancyetroland free.fr> May 25 2001
- NancyEtRoland <nancyetroland free.fr> May 25 2001
- NancyEtRoland <nancyetroland free.fr> May 25 2001
- NancyEtRoland <nancyetroland free.fr> May 25 2001
- Jan Knepper <jan smartsoft.cc> May 26 2001
- "Patrick vHAlkema" <pvha compuserve.com> May 28 2001
- Mark Evans <mevans zyvex.com> May 28 2001
- Damian Dixon <damian.dixon tenetdefence.com> May 31 2001
- Roland <rv ronetech.com> May 31 2001
- Damian Dixon <damian.dixon tenetdefence.com> May 31 2001
- Roland <rv ronetech.com> Jun 01 2001
- Mark Evans <mevans zyvex.com> Jun 03 2001
- NancyEtRoland <nancyetroland free.fr> Jun 04 2001
- Roland <rv ronetech.com> May 31 2001
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
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 23 2001
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
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
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
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
Jan Knepper <jan smartsoft.cc> Mark Evans wrote: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.
Ever tried FreeBSD? http://www.freebsd.org/ I am personally not too crazy about Linux out of security perspective. Too much hacking, too little structure if you ask me... Jan
May 24 2001
Mark Evans wrote:Yeah, they are sweet. However I consider DOS ugly, something that should have died a long time ago, especially for embedded apps.
Well, used DOS (and SCO Unix) for quite some time before Windows (NT 3.5) came along that was acceptably stable... I think Windows is ugly too, but that is just me I guess. The original ideas behind NT were great, but I am not too sure how many of these ideas are still part of 2000. Just downloaded SP2 yesterday... 104 Mb... Jan
May 24 2001
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
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 a écrit :2- pc-104 is ISA isn't it ?
i should read your messages more carefully .. Thanks againMark 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
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
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 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
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
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
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
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 DamianThanks 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
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
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
Mark Evans a écrit :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.
I agree Thanks everybody Roland
Jun 04 2001
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