SunOS real time problems

[EAJUAN at TOP.UPC.ES]

I have received several e-mails from different people all around the net,
all of them pointing out the unfeasibility of our approach and suggesting
alternatives to do what we are trying to do :

=1= Ladson Hayes (AP08 at PRIMEA.DUNDEE.AC.UK) suggests using a PC-front end
    to maintain the dialogue with the robot and then feeding the data
    into the Sun via PC-NFS.

=2= David B. Stewart (David.B.Stewart at FAS.RI.CMU.EDU) suggests using
    a M68020 single board computer (~5000$) in the VME backplane, running a
    real time OS (CHIMERA~II) developed in its lab, allowing the control
    of several processors.

=3= Bo Thide' (bt at irfu.SE) suggests using a HP9000 station with HP-UX,
    a UNIX version with real time capabilities and "hammer on Sun to make
    rewrite their UNIX kernel so it can support Real Time Unix".

=4= Charles ??? (unisoft!cander at ucbvax.Berkeley.EDU) pointed out the
    possibility of using a real time system running on Sun and distributed
    by Wind River Systems (Emeryville, California) which, even if it is not
    UNIX, it has a lot of Unix features. (--> VxWorks ??)

=5= Dan Messinger (dan at rose3.Rosemount.COM) suggests adding a Mizar MZ 7170
    board --a SPARC based processor made to run real time applications-- to
    the Sun, with VxWorks OS (Wind River).

=6= ?? (rowan at quandary.Central.Sun.COM) suggests using a real time single
    board computer such as the Heurikron to do the time-critical stuff,
    passing summary event information to the Sun host via some kind of bus
    technology.

=7= ?? (buky at cs.rochester.EDU) faced the same problem as us and they tackled
    it by making use of INTERNAL ALTER instead of EXTERNAL ALTER (this is
    PUMA jargon), that is, facing the problem from a more affordable
    perspective which does not involve the time critical requirements of
    the original problem.

=8= Jean-Christophe Kougoyan (sun!sunehq!sunfra!jckougo), Support Engineer
    of Sun in France confirmed me the non-appropriateness of SunOS to this
    kind of work.

=9= Elliott McCrory (mccrory at mdtf05.fnal.GOV) suggests using real time
    Unix workstations and cites two of them : Concurrent (formerly
    Masscomp) and HP. He has tried a Concurrent WS which seems to
    be able to guarantee an average response time of 2 to 3 ms.

=10= Alistair Conkie (adc at edai.ed.ac.UK) sent me the reference of two
    works somewhat related to the real time control problem of robots
    from Unix :
     Robot Manipulator Control under Unix - RCCL: A Robot Control "C" Library
     By: Vincent Hayward, Richard Paul
     In: The International Journal of Robotics Research v5n4 (1986)
    and
     Implementation of a robot control development environment
     By: Lloyd, J.
     In: M.Eng. thesis, McGill University, Dept of Electrical Eng. (1985)
    In the first one of them, "...they use a PUMA 600 and talk about modifying
    Unix (on a VAX) to provide real time control, but in a rather general way,
    as follows: the control software is executed in kernel mode at elevated
    priority. A special locking mechanism and linking procedure for keeping the
    control software in real memory were developed..."

I wish to sincerely thank all these people for their helpful suggestions.
After evaluating all their answers, what we shall do will be to compare
the performance of the system 1) when using the INTERNAL ALTER approach
suggested by =7= and 2) when using a microcomputer as front end for
guaranteing the dialogue with the robot controller, and then using the
most performant of both approaches.

           Joan Ilari i Valenti     EAJUAN%EBRUPC51.BITNET at CUNYVM.CUNY.EDU
           Assoc. Professor         EAJUAN%TOP.UPC.ES at CUNYVM.CUNY.EDU

        Institut de Cibernetica
        (Universitat Politecnica de Catalunya-
        Consejo Superior de Investigaciones Cientificas)
        Diagonal 647, Barcelona 08028, Spain
        Tel: +34 3 249.28.42