Newsgroups: comp.realtime,comp.os.qnx,comp.os.ms-windows.advocacy,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!jobone!heifetz.msen.com!zib-berlin.de!gs.dfn.de!gwdu03.gwdg.de!plewe
From: plewe@ks.mpi-dortmund.mpg.de (J.Plewe)
Subject: Re: Real-time systems:  Windows-NT or QNX
Message-ID: <GRGTBM6Q@gwdu03.gwdg.de>
Followup-To: comp.realtime,comp.os.qnx,comp.os.ms-windows.advocacy,comp.robotics
Sender: news@gwdu03.gwdg.de (USENET News System)
Nntp-Posting-Host: sk.mpi-dortmund.mpg.de
Organization: GWDG, Goettingen
X-Newsreader: TIN [version 1.1 PL8]
References: <FriOct14102309EST1994@eric>
Date: Fri, 14 Oct 1994 13:27:51 GMT
Lines: 105
Xref: glinda.oz.cs.cmu.edu comp.realtime:7121 comp.os.qnx:2189 comp.os.ms-windows.advocacy:40344 comp.robotics:14343

Bernie Kirby (bernie@ecr.mu.OZ.AU) wrote:

: wrong.  Third the system should be able to run multiple tasks so I guess
: MS-DOS is out of the question, though some people here (I suppose they
: include myself) think it might be a good choice if for no other reason
: than it's robustness.

You could use common Forth system running with MS-DOS. They commonly
allow the usage of multiple (Forth-controlled) tasks.

: In essence what we want to do is run a variety of tasks some at very regular
: intervals, so for these determinacy is a key issue, and others
: when certain events take place such as a key-hit. Each of these tasks might
: correspond to a conceptual level in the controller. We will be dealing
: with the control task from very low levels to high levels. At the very
: lowest levels will be control loops such as PID loops for robot joints.
: Force control will be at the next level and trajectory generation at a
: higher level and so on. The highest level would be a graphical user
: interface of some type though its not quite clear what is required at that
: level. 

Should be no problem with a Forth system. I know that some commercial
Forth system (ask me for references) even supply graphical user
interfaces, so the range you describe is covered.

: The lowest levels (PID loops and force control loops) would be the
: most important parts of the system so they would have to get priority.
: They need to run at rates between 1000 to 2000 Hz so I suppose accurate
: facilities for timing are needed. Should these tasks run inside interrupts
: connected to a clock or should they run as separate tasks?  Is it best
: to have a rate generator board or can be the PC's clock be used?

You are joking, are you? Recently I did real-time control with a resolution
of 20kHz using a PD Forth system. I was just using the (modified, software
only) DOS clock, but there are other possibilties. When you intend to 
read external signals with this frequency, you will not have to deal with
interrupts, but can easily poll in a task.

: programming. Robustness is an important consideration so bearing this in
: mind which scheduling approach is best suited to our problem.

Forth is normally using the scheduling strategy you like best. You should
be aware that the simpler a is system is, the more robust it will be.
When your problem allows to use a simple round-robin tasker, you should
use it. When you use a a full featured RTOS, you maybe cannot choose.
In Forth, you can!

: One of the most important considerations is ease of writing device
: drivers.  We don't really want to get bogged down in this area. Both
: systems claim some level of POSIX compatibility so I guess devices are
: accessed in both by open/read/write etc calls. How do the systems compare
: in terms of ease of writing device drivers for things like A/D boards
: Digital I/O boards, etc. Are drivers readily available?

When using a simple system like DOS, this should be no real problem, eh?

: When it comes to the windowing tasks I suspect that windows has the
: performance advantage since that's what it's really designed for.  What we
: need to make sure of here is that the processor doesn't get bogged down
: updating the screen or running the user  interface when the servo control
: tasks must run.  

Then you better should forget Windows. Windows tasker is cooperative. Whne
Windows decides to perform a redraw than you servo will have to wait. The
only realtime control under Windows up to my knowledge is to use the
multimedia extensions. 

: The intended application for the robot is hazardous and if the software
: failed the potential for disaster is great. I know we have to take
: responsibility for our own bugs but which systems is more reliable
: or robust. Is there any type of certification for computer systems that
: must run in hazardous environments. Does either windows NT or QNX have
: such certification. Failing that, it would be nice to know which operating
: systems has the best track record. Are there well known examples where
: each is used in a dangerous environment.

Again, forget Windows. I crashes when it likes to. Forth systems have been
proofed to run roboters under difficult circumstances.


: Any thoughts what-so-ever would be greatly appreciated.

Forth development systems are typically simple, straight forward and
robust. Perhaps you should think to this direction. In this case I
would advise you to have a look to the group comp.lang.forth. 
There are frequently postings of people having done whta you intend to
do.
 
: Bernie.

- Joerg



\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_                                                                          \_
\_ Dipl. Phys. Joerg Plewe                  Joerg.Plewe@MPI-Dortmund.MPG.de \_
\_ Max-Planck-Institut fuer molekulare Physiologie                          \_
\_ Rheinlanddamm 201, D-44139 Dortmund      +49 (0)231 1206-218   Fax: -464 \_
\_                                                                          \_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

I am not under the alkafluence of inkahol that some thinkle peep I am.
It is just the drunker I sit here the longer I get.

