A Case-Study of CAM Software Development

A Case-Study of CAM Software Development

A Case-Study of CAM Software Development G. Lindholm, Royal Institute of Technology, Stockholm/Sweden - Submitted by G. Sohlenius, Royal Institute of ...

292KB Sizes 27 Downloads 122 Views

A Case-Study of CAM Software Development G. Lindholm, Royal Institute of Technology, Stockholm/Sweden - Submitted by G. Sohlenius, Royal Institute of Technology, Stockholm/Sweden (1)

This pnpcr dcscrihrs the dcvelopnrnt of a systcri skctch for :I graphic interactive opcratinns planning Wstcm. The system sketch w:is davelopcd using t h r e r progrnnming tools; CPYl, PS-Iih :in
.

.

1.

Introduction

This paper describes the dcvelopment of a system skctch to a graphic interactive opcrntinns planning SySten. Thc s:Jstem sketch and the expcricnces gained a r c intcrestina fron scvernl aspects :

-

A fnirly complicated svstcm was devcloped hv uvskillcd personncl in an unusunllv short time.

-

The opcrntions planning svstcm skctch i s hased upon n gcncrnl prickape for product nnd geometric modelling. This is interesting. when consitlerine: tlic comnunicntion betwccn C A D and C h l l svstcns. If both CAT? imd CAP! systems arc hnsetl upor penernl riodellcrs then comniiniortion cnn he facilitated.

-

The operations planning systen sketch i s based upon n general pnrk:igc for man-motlel intcrnctinn. General graphic packages, such ns CPGS. GINO-F nnd lC1, have been used profitably for many years. The package usctl (PS-lib) iS similar to an cxtendcd graphic p c k a g e .

-

Graphic interactive progranning tools were used, and repl;iced some traditional codinc at ;in nlfnnumcricnl tcrninnl.

The functions availahlc in the opcr:itions planning systcri sketch nre not imprcssive; in fact we An not even want to call it an opcrntions planning system. I t I n c h many of the fa that niust be prcscrit in a operations planning system. So, it i s not the system itrjclf thnt is intcrestiqg. hut the cnsc of tlevelopnent and t h e powcrful tools that wcrc used. The product modeller will be described in section 2 . t h e man-nodel conmunication package in section 3 and the Creamenu proaram in section 4 . The operations planninq s y s t e m sketch itself is dcscrihed in section 5 . together with iin account of time, costs rind personnel used. Section 6 contains the mnclusions. ?.

The product nodcller, GPFl

that the opcrntions plnnning systcm sketch iises graph ohjects find volune objects sinultnneousl-1

.

The geoeietric domain covered by the OPM Volune nodulr is tho followin$: Curve typcs that can he reprcscnted are straight linc, circle. cllipsr , pnrnholn, hypcrboln and uniforn H-spline. Surface types availnhle :IPC plnnc, cylinder, cone, s p h e r e , general qundric and torus. A l l purfnccs arc r e p r c s c n t 4 analytically , and not using a faccttotl rcpproxinqtion. IJote that sculptured surfaces are not in the qeometric dorinin covered hy the CPN Volume module. This cnused no prnhlcn for thc onerations plnnning systcm sltctch. since i t does !lot necd sculptured s u r faces. I!owever. an application that does nccd models including sculptured surfaces can use the OP!l Sculptured Surfaces nodulc <1, 3 > .

es to crcnts product nodcls, containing more data than just the p x n s t r y of an object. A dntn Struct u r c for help geonctries, technical diltii, connections anc! nodit'ications attnched to ohjects, P S well as suhroutincs to Create nntl delete these nuxilinry data are supplicd. Finally, there is a WII:J to define "general groups". One cnn e . g . tnkc a n u n b c r of faces, that forn a slot in an object and pirt tlicni into a general group. In this cvny, fcaturcs can he r!cfined in the ohjects at the user's will. The typos of fcntures find aiixiliary r!ata that can be clcfined ore not restricted to :in!r predefined set. The application programmer can define any data he wants. Thcy can h e very problem-oriented, which considernhly eases t h e tlcvclopmcnt of applicntion prngrans. A n cxnmplc where product nodcls can h e needed, is if one wants to model n letter-scelc, R S in figure 1. In this cnse, one wants to keep datn in the model nhout the nnteiinl of the parts and how they arc connected. With these datn in the nodel. one can e . g . compute how much the scnlc will swinR. whrm a given force i s put on it. If only qeomrtric nodels firr used, this calci" inn can not bc done.

GPYI, Geometric Product rlodels, W R S tho name of an internordic joint research project <1, 2 > . Within t h e CPrI project, four software nodules were developed. O x of them is the GPF.1 Volune module. This is R subroutine package, that perforns econetric nodelling nnd product nodelling. It can handle wircframe nodels, internnlly cnlled "graph objccts" Thcsc always lie in a three-dimensional coordinnts system. I t can also handle "Ianina objects" and "shcll objects", which arc infinitely thin obiects, useful when one is modellino; shcet metal parts. The laminn and shell objects are similar to surface models, but sone differences can b c nentioned. A. lamina ohjcct in the CP?l Volume module has B "front side" and a "hack side", either of which can be swept b y n given distance to prnduce a volune object. So, laminae and shells nrc more than a nathenaticd surface. T h e r also have a topologv, i . e . faces, contours, edges and vertices. There is I? data s t r u c t u r e defined for t h i s , that i s very sinilnr to the data structure of t h e volume objects.

F

.

The volume object, sometimes called a solid model in other systems, is the fourth type of object available in the GPIl Volume module. These, and also the lamina ohjects and shell objects mentioned above, a r e represented using a boundary filc type data s t r u c t u r e . Several "copies" of an ohject can be placed (instanced) in a global coordinate system, and put togethcr in a group-of-objects (nsscnbly). The group-of-objects is also considered an object, which in i t s t u r n can he placed and put into enother group-of-objects. In this way i t is possible to model assemblies, made up of subassemblies, some of which a r e also nndc up of suhnnsemblies. An assenbly can contain c . g . one volume ohject nnd one graph ohject; the different objects can h e mixed at the user's will. This increases his possihilities, to model what he really wants to model and always with an appropriate model type. l a t e r in this paper, we will see

Annals of the ClRP Vol. 32/1/1983

Fig 1 A lettrr-scale c a n be ;e?resentec>

by

d

r)roduct model

375

In the operetiom planning systen sketch, technical data are used to represent the feeds and speeds, and to some extent to represent the milling depth. The CPM Volume nodule is written in Compatible Fortran. It w n s tlevelopcr! on V A X and CDC machines, but can be run on virtunllo any nnchine. We do recommend, however, 32-bit machines or larger, with largr virtual mmories. In totnl, there tire some 600 routines, containing 100,000 lines of Fortran source code, of which 60,000 lines are comnents. It h a s n graphic interface and a databnsc interface thereby naking thc nodule independent of which graphic package and DRMS are to be used at a specific site. 3.

The nun-nodel interaction software, PS-lib

This software package is a set of subroutines to be used by an applicatior! program in the same wny ns QPI.1. One group O f routines in PS-lib pcrforns vicwing and windowing, Iilre most traditional graphic packages. PS-lib keeps an own graphic model of the picture, with references back to the product model in GPbl. The graphic model is an untransformed segmented display list. Onc group of routines, thut are called by GPGI, creates the graphic model. Thcn there is one group of routines that makes the scgnents in the graphic nodel visible on the screen. In the graphic model, there arc also data nbout the n e n u and commands that have been defined, where on the screen they are to be displayed, if they a r e "on" or "off" etc. There i s a routine group to hnndle these menus This group will create new menus , create connand and menu texts, blank and unblank menand also pass crror messaces nnd help messages to the operator at the terninal.

.

There i s also a group of mutines to inquire about user interaction. These routines will accept input fron anv device. These routines keep track of the menues and wether they are visible or not. They also "lmon", using the graphic model, which parts of the product model that are visible on the screen. When they are interrogated concerning user actions, they can report "The user has pointed at command 4 in menu 3" or "The user has picked edEc cl2" or "The uscr has given the value 36.28". In this way, the applicntion program does not have to check the interrupt queue, find an interrupt that corresponds to pointing at a tablet and t r y to figure out what thc user pointed at. All this is done by PS-lib, and this makes applicntion propcuming even easier. Anothcr nicc facility in PS-lib, when running on a Multi Pict u r e System with control dials, is that tho user can turn the knobs and thereby rotate, move and zoom thc picture on the screen. This affects the picturc on the screen only, and not the product model at all. Therefore, the subroutines to handle such transformations were put into PS-lib, and the npplicntions programmer can use them when desired.

The applications programmer sits down at n graphic workstation and starts the Creanenu program. The program then asks him how many menus he wishes to have, and what their menu numbcrs are. He is then requcsted to draw the menus on the screen, at their desired positions. The Creamenu procram always creates menus with straight lines and right angles. even though the applications programmer can't draw thcsc exactly. Finally, the applications programmer to put in the command and menu nnmes, and the command "hit areas". Notc that the command hit nrea is normally FjlightlV snaller than the command's rectangle i n the menu, so the routines (lo not accept if one points extremely closr to a line in a menu. One must point well within a command rectangle, to have the pointing treated as a valid command. Just before the program exits it creates a file called DRAWFlENU .FOR in the current default direetorv. This file contains a Fortran subroutine, with the name nRAI+WENU. The subroutines in PS-lib that define rnenues are called by this subroutine. Exactly how many calls there are, in what order thev are and what parameters they take are dependent upon the commands that wcre givcn to Creanenu. The DRAWMENU subroutine can be directly compiled and linked together with the main program. The operations plnnning system sketch

5.

This program <4> was created under the following circumstances. We hnd a newly enployed, newly graduated person, who Inter would work with CAD-CAFl, especiallv process planning. He needed to learn the hardware and software facilities available. and he needed to refresh his knowledge of Fortran. That was the personnel available. The software that was available has already been discussed. The available time was two months. The total funds available, including all overheads such as computer time, administration etc, was SEK 50.000. In t h e operations planning system sketch, which is subsequently referred to a s the "Milling example", the user i s shown a menu in which the tool, blank and chuck can be chosen. These nre prc-defined, and they are fetched fmm files. Then a new menu (figure 3) appears, for creating toolpaths. Now the user can interactively define new segments in the toolpath. Segments can be straight lines, circular arcs or complete circles. Segments can of course be deleted too. During the interaction. GP?.1 i s called to create 8nd update the modcl of the toolpath. TOOL PATH

I New toolpaths1I Linear move

I

Delete l a s t

Fiq 3 .

I

Main

I

Program

I

Svstem a r c h i t e c t u r e i n t h e o n e r a t i o n s n l a n n i n q s v s t e m sketch

Visual check

I

Reset

1

Exit

Main menu i n t h e m i l l i n r c example

So far, the toolpath lies only in a plane with data about the depth connected to it. It is of course possible to evaluate the toolpath and see it in a 3-dimensional space. One can also point at a place on the toolpath and have the tool moved there. In this wsv it i s possible to check visually for collision. There i s no automatic collision detection in the progrnn. Of course this could also be done, since volume models are used to represent the tool. the blank and the chuck.

Findly there is an HC code generator in the program. This takes the QPhl model of the toolpath a s input. Using this it creates the NC code for the machine we use, an old Zjdimensional milling machine. Then an NC tape can be punched and the workpicee can be machined.

The Creamenu program

Even if 811 menu handling i s done hy the subroutines in PSlib. the applications programmer have to call the mutines in PS-lib to define menus and commands. This oftrn means writing code in Fortran. Such code always contains at lcast onc more b u g , that is hard and time-consuming to find. The idea behind Creamenu i s to have a graphic interactive program, that will produce the Fortran code.

376

I

I

'P Graphic workstation

4.

Technical data

I

The use of technical data in GPC.1 i s especially interesting. In the millinp: example, one wants to hook the extra data that "this movement i s a fast feed movement, not a milling novement" to some segments in the toolpath. When using GPPl a s a modelling tool, this is extremely easv. One just defines a technical data entity b y a GPI.1 subroutine call and connects the data to the segment of the toolpath with another GPPl subroutine call. The same method has been used to implenent the depth of the cuts. Tho user gives in the depth on a "keyboard menu", similar to the keyboard of a pocket calculator. Then it i s connccted to the segments a s technical data.

Product Node 1

Fia 2 .

1

]Circular move IArc move IGo home

I

6.

Conclusions

An operations planning system sketch has been developed. The system sketch as such i s not a s interesting a s the way it was developed. the tools that were used and the small amount of resources that were required. The experience i s that standard packages for product modelling and man-model interaction greatly reduce the amount of code that has to be written. The

1 I

Fig 4 .

P e r f o r m l n a o i s u n l check i n the millinn examnle

number of e r r o r s in the codc that has to be written cnn be reduced i f one i s using automatic programming aids like the Creamenu program. These factors made it possible to develop n quite sophisticated system in only two man-months.

I.

Acknowledgements

I'd like to exprrss m y gratitude to Hans Filsson, who wrote the milling example and to Per Cnrleberg who wrntr the Crcanenu program and PS-lib. I also would like to thank Ian Stroud, Lars WingArd and nll other, current and past members of the GPrI group who wrote GPM. Finally. I thank D r Torsten

Kjcllberg and Prof Cunnar Snhlenius for continous advice anc! encouragenent. The work described in this pnprr has becn financiallv supported by the National Swedish Board for Technical Development and the Nordic Industrial Fund. 8.

References

<1> "Geometric Product Plodels. An Internordic Joint Pmjert" Information report. I S B N 87-981360-0-3. 1982.

.

<2> C Ilaglund, T Kjellberg. G Lindholm. 1 Stroud: "GPM report 18. Systen Specifications, Volume Geometry." ISBN 91-85212-64-4. The Royal Institute of Technology, Stockholm, Sweden. 1981. <3> S Ulfsby et al: "GPPI report 21. Reference Manual. Sculptured Surfaces." S I , Oslo, Worway, 1982. Milsson: "PS-info DP 198?/12, Llilling example users guide". The Royal Institute of TcchnoloEy, Stockholn, Sweden. (Written in Swedish)

<4> H

377