Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request
From: sxm@philabs.philips.com (Sandeep Mehta)
Newsgroups: comp.sys.sun
Subject: Re: SunOS real time problems
Keywords: Miscellaneous
Message-ID: <3809@brazos.Rice.edu>
Date: 3 Dec 89 13:46:02 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 40
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n207, Replies: v8n215
X-Sun-Spots-Digest: Volume 8, Issue 218, message 6 of 15

In article <3299@brazos.Rice.edu>, EAJUAN@TOP writes:
>Our main problem is the following one : we have a PUMA 560 robot (with a
>MK-II controller) connected through a serial line to the Sun workstation.
>To maintain the dialogue with the robot we must make sure that the host
>will answer the messages sent by the robot controller (each 28 ms.) before
>receiving the following message (that is, within the next 28 ms.).  We
>have tried working with the Sun as single user, raising the priority of
>the process, etc... but it seems that there is no way of making sure that
>the workstation will answer the message of the controller within the
>alloted time. In fact, the program maintains the dialogue during a
>variable number of intervals. Then, it fails to answer within the 28 ms.
>period and the communication is broken.
>
>Has anybody some idea about how to guarantee an answer of the workstation
>within a given time period ?
>

We control our PUMA using Sun 3/160s. The main difference is that we don't
rely on Sun/SunOS for anything real-time -- the usual UNIX and real-time
are mutually exclusive scenario :-). We have a VME cage memory mapped into
the Sun. The VME cage has numerous 68020 single board computers and 8 Mb
of common memory on the bus. There is a run-time library that provide all
the (UNIX like) primitives necessary for writing real-time applications on
the multiprocessor cage. We talk to the PUMA via the sbc's serial
(RS-232/422) port which is connected to the VAL controller. We are
planning on running some timing experiments to determine a bound on how
fast a real-time OS on the VME cage should run for smooth control of the
PUMA. The r-t OS is currently under implementation.

I know my answer hasn't really addressed your problem but I think by
stressing the inability of UNIX to handle "true" real-time in the robotics
domain I've tried to address the root of your problem.

Given the vanilla UNIX environment, particularly the stock SunOS scheduler
I don't know if you can ever guarantee meeting *hard* deadlines reliably.

sandeep

sxm@philabs.philips.com
uunet!philabs!bebop!sxm                             ...to be or not to bop ?