Is there any real time coded scheduler programs /C or delphi sources OT. I wan't to write a windows app in either Delphi or C++ Builder to control a few hundred remotely controller AVR's with a Gantt type of interface.
Andrew
In the context of this newsgroup "real time" and "windows app" are mutually exclusive.
Peter
I have a page about a busdevice server, in my case it was an RS422 bus with dozends of devices, each having its own application interface on the PC.
The realtime functionality was on standalone working devices, they were just managed from the PC.
Rene
-- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Then maybe you should upgrade your 486's
*runs*
The speed of the processor (assuming upgrade means that) has no bearing on the issue. A real time OS is one that provides a guarantee that a task will be performed within a deadline (like within the next second, or year). Windows may typically respond well within a second but it does not guarantee it and in some cases can defer tasks for an *arbitrarily* long time. Increasing the speed of the processor just increases the probablility that work will be done by the deadline but it still doesn't guarantee it. Hence my comment, which BTW you fail to attribute.
Peter
[...]
(Snipped information that's redundant in the context. ;)
-- http://www.flexusergroup.com/
If you understood what windows is running exactally you can garantee something will happen within a finite time. Reguardless of it or not the system can 'truely' interrupt make no difference. If windows is configured properly (disable all vm and services and ringrot the kernal, not to mention embedded windows) and used with flash memory IDE type drives you can ensure something in a determined time. Just as you can ensure an embedded system would do something in a determined time via polling.
It really comes down to implementation dependant. But just because he asked to control a few hundred avr's in real time doesnt mean he has to have an embedded solution. We use windows PCs to control servo motors on robots and they have never failed to act within the 50uS through the maybe billions of signals, and even if they did depending on the application a small delay is hardly going to make big difference.
You act as if windows just randomly runs whatever whenever and you never know what is going to happen when.
that
Hence
mention
ensure
asked
and
of
is
How is anybody going to know who 'you' is if you don't attribute the quotes?
I understand perfectly that windows will probably be OK for many time based applications where 'a small delay is hardly going to make a difference'. Perhaps I am just quibbling about the use of words and what I percieve them to mean but real time, as in real time operating system (RTOS), means something that windows isn't and nor does it aspire to be.
Peter
This is the key point. Windows may be appropriate if failure is not a problem.
Many posters on this newsgroup work with critical systems, where failure to act may result in significant damage to people or property. If something bad may happen if you fail to act, you MUST NOT use windows.
Some years ago some hybrid devices we used were recalled. The devices had been etched using a PC running windows and someone had added a network card to the machine. The end result was that the machine paused for brief periods while Windows was talking to the network card. The pause was long enough for a small hole to be etched in the case.
Which is, in fact, precisely the case.
In order for this not to be true, we would need to see APIs in Windows that state things like "This function is guaranteed to return within ms, given that a watchdog reset is not in progress". (oversimplification of course).
I don't care what type of drives you have watch any windows totally lock out all other processes on corrupted media. Does not matter what type I have seen systems go into exclusive mode looking at the drive trying to wait for the drive to give useful information as it does 'n' retries. Even flavours of XP!
Don't say the next version will sort this.
If ANY of the processes running can take exclusive control of the system locking out other processes then the response time of the system is NOT guaranteed.
If seen similar problems, with network connections dropping and the system locking hunting and retrying to find the network resource. See what happens on a desktop on moving round a window on screen.
If it has no media, no graphics (headless) and no networking you may well get there.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
I don't really disagree with any of you guys im just saying that in some instances you can guarantee processes will not lock (since you coded them!).
It's (relatively) easy to be sure that your own self-written processes don't lock up, except of course if windows locks them during system calls. But you have no way of knowing what other processes are running. With a great deal of effort, you can limit a number of them, but you can't get them all. They are not specified in any way, and there is no available source code. Generally speaking, you don't even know who made them - typical windows systems are full of third-party code, even if it is stamped with Microsoft's name. There are processes running that don't show up on any lists such as task manager, and no way to control many of the tasks that do show up.
Windows can be a convenient platform for many uses, but you have *no* guarantees, and it cannot in any way be described as a real-time operating system. It might well be good enough for the job in hand, and it might be possible to provide empirical statistical evidence showing
99.99% timing correctness, but you have to be able to tolerate the 0.01% occasions when the OS decides that now would be a great time to defragment the hard disk.If you want a reliable windows system with tight control over the running processes, you are better off with Windows 3.1.
Thank you! For a sensible reply, instead of a lecture on what some people might think RT means.
To add more detail, your stuff is the sort of thing I had in mind, at least for the device interface part of the application. I found a few Gantt Chart applications (Project management), but couldn't download them.
Excuse my use of language in the title of the thread. My application has response times that would happily be minutes not nanosecs. And the process runs over days. The communication is at half-duplex 9600 baud, using packets not char by char. Given this, are there any windows things I can do to guarantee no lockouts or that I at least get my share of processing time. I would assume the platform will be at least NT,2000,XP or a dedicated 98 machine, so crashs shouldn't be an issue.
Andrew
The answer is no, there are still no guarantees, and crashes are still an issue. In practice, Windows will be perfectly good in this sort of setup (although you will have to remember to turn off all the "automatic" stuff windows does, to be "helpful" - automatically installing updates is going to disrupt even the slowest communications).
Technically, "real time" means you require guarantees on your timing, even if it is at a level of minutes. You can't expect true real-time performance from windows, of any version. But for the sort of thing you are looking at, you can expect that it will be perfectly usable.
"Andy Sinclair" schreef in bericht news: snipped-for-privacy@4ax.com...
How many is that, 12 out of 1784? Anyways, the 12 that do, don't need to be warned, I'd think.
What a load of BS. Property damage may be at risk more often, but 'failure to act' should not lead to (large) damage anyway, with any sensible system. Oh, and it isn't even 'failure to act' that is the greatest problem. A failing sensor, a bug in the software, operators entering wrong parameters/recipies, those are often the more important reasons that lead to serious damage.
More BS. You just shouldn't allow some jerk mess around with such system, like you wouldn't allow with any kind of critical system. Yes, it runs windows, no, you can't use it to download new screensavers.
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
I'd recommend to offload the realtime functionality to an embedded cpu. Use the PC to communicate with this embedded device(s). It is much simpler to have an embedded sytem with a few thousend lines of code running in realtime and flawless and on a few miliamps, than a PC with multiple caches, virtual memory, pagefiles, garbage collection and so on. Design the system such that it runs with a PC that has an unreliable timing.
Rene
-- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
I tried to compile your code in delphi3, and got a fatal error file not found MyMsgQueue.dcu Is that the same code as MsgQueue on and where do I find the Delphi Forms?
Andrew
Include me in the critical systems bit. I've worked on:
- temperature controllers, where loss of control could lead to thermal runaway. (One system I saw was in charge of a large vat of lipstick - yuk! - with a few million dollars-worth in the vat at any one time. Loss of control would probably not have hurt anyone physically in that case - but commercially and financially, definitely.)
- fire alarm and safety surveillance systems, where my code was directly responsible for the safety of e.g. personnel on oil rigs
- GPS-based safety systems, where an oil ship was connected to a sea-bed oil pipe, and my system monitored the distance from the bow connector to the oil connector. If my system went doo-lally, not only would a big mess and a lot of damage result, but there'd be a serious risk of fire and explosion.
- TV broadcast talkback and robotic camera control systems - where a failure could a) hurt someone (the cameras had a lot of inertia) and b) be very public and very embarrassing.
Amongst others.
Amen, brother. The thought of a desktop Windows system running my kind of app fills me with abject terror.
Steve
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.