Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request From: EAJUAN@TOP.UPC.ES Newsgroups: comp.sys.sun Subject: Re: SunOS real time problems Keywords: SunOS Message-ID: <3743@brazos.Rice.edu> Date: 4 Dec 89 11:38:00 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 77 Approved: Sun-Spots@rice.edu X-Refs: Original: v8n207 X-Sun-Spots-Digest: Volume 8, Issue 215, message 6 of 12 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@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@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@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@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@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@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@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@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@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@CUNYVM.CUNY.EDU Assoc. Professor EAJUAN%TOP.UPC.ES@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