Interfacing CAD and Manufacturing Cost Estimation Software using COM/OLE

PROCEEDINGS OF THE INTERNATIONAL CIRP DESIGN SEMINAR KTH STOCKHOLM, SWEDEN, 6-8 JUNE 2001, PP. 289-294 Interfacing CAD and Manufacturing Cost Estimation Software using COM/OLE Y. Liu, A.H. Basson Department of Mechanical Engineering, Stellenbosch University, Stellenbosch, South Africa Abstract: This paper presents a case study in which COM/OLE technology was used to develop a link between AutoCad and the Cost Estimator (manufacturing cost estimation software developed by the authors' research group). The link is intended to assist designers in relating AutoCad geometric entities to manufacture features quickly and easily. It demonstrates the use of COM technology for developing an interface for linking different applications written in different computer languages. Keywords: AutoCad, Computer Interface, Component Object Model 1 INTRODUCTION Great emphasis is placed on reducing manufacturing cost through product design. It is widely accepted that about 70% of the life cycle cost of a product is fixed during the early design phases. There is therefore considerable interest in developing design tools and aids for the online cost estimation at early design stages. These tools are required to give designers quick feedback to optimise their designs. In other words, effective integration of conceptual design, conceptual process planning and cost estimation is required. Research in this area has received considerable attention in recent years, e.g. Hill et al. [1], Peng and Trappey [2], Jayaram and Myklebus [3], Bidanda et al. [4] and Leibl [5]. For AutoCad applications, Tsai and Chang [6] have produced a geometric tolerance definition system, and Zhao and Ridgway [7] developed a CADEXCATS software package to assist in the selection of tools for turning operations. Previous research often used neutral data exchange formats, such as IGES, to transfer information between software applications. This approach limits the information to the types provided for in the neutral format's specifications. It does further not allow for selective updates, such as when a part of a design has been changed and a corresponding update of the manufacturing cost estimate is required. To overcome these limitations, specific software can be developed to interface two or more software packages and facilitate data transfer between the applications. The authors' research is aimed at manufacturing cost estimation during the later phases of conceptual design and the early phases of detailed design. Many design decisions regarding manufacturing aspects are made during these phases, and cost estimations (even though they may be crude) will be very valuable in trade-off studies. During this phase, however, the CAD models will typically be incomplete as manufacturing decisions have to be made before all the finer details of a design can be included in the CAD models. Cost estimation during these phases therefore requires inputs from the designer. These inputs are typically the intended (or candidate) manufacturing processes and quantitative information about the manufacturing features required for obtaining a cost estimate. Some of the quantitative information will usually be present in the incomplete CAD model. 2 LINKING CAD AND COST ESTIMATION SOFTWARE The preceding section clearly indicates the advantages that can be gained by linking the manufacturing feature information needed to the appropriate geometric entities in the CAD models. Establishing such a link will ease the work of designer, and also prevent inconsistencies between the CAD model and the cost estimate. In the design phases targeted in this work, frequent design changes must be expected. Frequent updates of the cost estimate must therefore also be done. The software link should expedite these updates. This paper presents a case study in which COM/OLE technology was used to develop such a link between AutoCad and the Cost Estimator (manufacturing cost estimation software developed by the authors' research group). The link's main functions are to allow the designer to relate AutoCad geometric entities to manufacture features quickly and easily, and to facilitate cost estimation updates (after design changes) with the minimum user input. Such a link has to interact with both the CAD and the cost estimation software. As the cost estimation software was developed in-house, its source code could be changed to facilitate interaction. This route was not available for the CAD software. Microsoft Windows-based software can provide a variety of interface options, such as OLE/COM/ActiveX or Visual Basic for Applications (VBA), e.g. Cottrel and Gao [8]. COM (Component Object Model) is a client/server object-based model designed by Microsoft to enable interaction between software components and applications independently of the languages they are written in. Liu [9] introduced a component framework of advanced CAD/CAM applications (CFACA) for featurebased design by using COM technology. Section 4.1

briefly outlines the distinctions between OLE, COM and ActiveX. AutoCad provides a number of interfaces for software interaction. These interfaces and their application in the work presented here are outlined in Sections 4.3 and 5. Using such an interface, a software application can access geometric information in an AutoCad drawing (such as the volume of a 3-D solid, the area of a face, the length of a line, etc.) and communicate it to the Cost Estimator software. 3 THE COST ESTIMATOR The Cost Estimator is software that was developed for estimating the manufacturing cost of components and/or assemblies during late concept design or early detail design. The designer can use it to get information such as the material cost, manufacturing cost and total cost of a component or an assembly. The designer can thereby compare the manufacturing costs of design alternatives (e.g. changing the part geometry or using different manufacturing process) and optimise the design accordingly. The Cost Estimator forms part of a larger "Design Assistant". Figure 1 shows the framework of the Design Assistant, with the Cost Estimator's actions in the last three rectangular blocks. Project Selection Problem Assignment yes Project exists? no Project Generation Project Definition a process has been included, the particular elements that comprise the process must be selected from the process library. The information entered in this step constitutes the Concept Process Plan. 3. The user must then provide the appropriate quantitative information for each process element. After completing the entry of the data, the user can examine the manufacturing costs of the design, thus identifying aspects where redesign can have the greatest benefit. The influence of parameters, such as batch size and make/buy decisions, can easily be assessed. All of the data entered by the designer can easily be changed, thus allowing easy evaluation of alternative designs and processes. Explanations of the processes are given to help the designer to consider processes with which he/she is not familiar. Figure 3 shows the cost calculation user interface of the Cost Estimator. Project Assembly1 Assembly2 Part 1 Part 2 Process 6 Process 7 Stock 1 Process 1 Process 2 Process 3 Stock 2 Process 4 Process 5 Specification Development Figure 2: Structure of a Project. Conceptual Design Concept Embodied Design Proposal Defining Assembly Structure Setting up Preliminary Process Plan Estimation of Direct Fabrication Cost Embodied Design Figure 1: Framework of the Cost Estimator in the Design Assistant [10]. To obtain a cost estimate, the user must enter a variety of geometric and manufacturing information (Figure 2) in dialog boxes: 1. The project, assembly structure and bill of materials must be entered into a tree-structure. Each assembly or part's name, description, drawing number and quantity has to be entered. Stock materials must be selected from a stock library. 2. The tree structure is then expanded by adding the manufacturing processes to the same hierarchical level as the sub-assemblies, parts and/or stock materials required to produce a certain part. Where Figure 3: Cost Evaluation in The Cost Estimator. 4 PLATFORM ISSUES AND COM TECHNOLOGY 4.1 COM/OLE/ActiveX An extensive range of options based on COM is available for interfacing different Windows programs

[11]. Due to space restrictions only a very brief outline of some of the most common terms is given here. COM is a widely-used component software model. It is an object-oriented programming model for building software applications made up of modular components. COM allows different software modules, written without information about each other, to work together as a single application. COM object creation is language independent (e.g. COM objects can be written in many different programming languages). It enables software components to access software services provided by other components, regardless of whether they involve local function calls, operating system calls, or network communications. COM is also the basis for ActiveX controls, controlling other programs via OLE automation and communicating with objects or programs on other machines (DCOM). OLE (Object Linking and Embedding) is a mechanism that allows users to create and edit documents containing items or objects created by multiple applications. OLE documents, historically called compound documents, integrate various types of data or components. ActiveX is a component-level technology for building applications from reusable parts. It is a subset of COM. An ActiveX control is an active object that may provide interactive or user-controllable functions from within another program or container. It is essentially a COM object in disguise. The primary difference between an ActiveX control and a COM object is that an ActiveX control has a design-time interface. Automation, in this context, is a technology that is based on COM, which enables interoperability among ActiveX components, including OLE components. It was formerly referred to as OLE Automation. Figure 4 illustrates the interrelationships of the technologies mentioned above. OLE Linking Embedding In-Place Activation (Visual Editing) COM OLE Figure 4: COM technology architecture. 4.2 Borland C++ Builder and Delphi ActiveX Controls Type Information C++ Builder and Delphi are object-oriented environments for rapid development of Microsoft Windows applications. C++ Builder is based on C++, and Delphi is based on Pascal. They have similar development environments. Delphi modules can be included in C++ Builder applications and the Delphi routines can then be called by C++ Builder routines. The Cost Estimator was developed in Delphi, and the software linking the Cost Estimator with AutoCad was developed in C++ Builder. The decision to use C++ Builder rather than Delphi for the link software was induced by requirements for future development of the software and collaboration with other research groups. Both Delphi and C++ Builder provide strong support for COM technology and have various functions that can be used to interact with the AutoCad Automation Object through the COM interface. Using these facilities, the link software can access the AutoCad database, get the geometry information from the drawing that the user specifies and then convey this data to the Cost Estimator. 4.3 The Development Tools of AutoCad AutoCad provides various routes for software developers to interface with it [11], i.e. AutoLISP (Auto LISt Processing), ADS (AutoCad Development System; C- based), DCL (Dialog Control Language), ARX (AutoCad Runtime extension; C++ based), VBA (Visual Basic for Applications) and COM/OLE/ActiveX. ARX introduced the concept of communication with AutoCad "objects". The authors initially considered using ARX to develop the software linking the Cost Estimator to AutoCad, but AutoCad only supports Microsoft Visual C++ in ARX. Since objects (or classes in C++ terms) have to be passed to and from DLL's when using ARX, the link software would have had to be developed in Visual C++. However, interfacing Visual C++ to the Delphi code of the Cost Estimator was considered to be impractical. Since COM/OLE/ActiveX is intended to provide software interfaces independent of the compiler being used, this route was chosen instead. The AutoCad ActiveX Automation Object provides a mechanism to manipulate AutoCad programmatically from within or outside of AutoCad, by using COM technology. It does this by exposing various AutoCad objects to the "outside world". Once these objects are exposed, they can be accessed by many different types of programming languages and environments such as AutoCad VBA, MSWord (or Excel) VBA, C++ and Java. A geometric entity in AutoCad, which is exposed as part of the Automation Object, has methods and properties that can be queried directly without understanding the internal database structure of AutoCad. Programming with COM automation is therefore simpler than programming with ARX. Figure 5 show the AutoCad Automation Object and the inter-relationships between the objects contained in it. AutoCAD Application Preference Document Block Dictionaries DimStyles Groups ModelSpace PaperSpace Block Dictionary DimStyle Group 3DFace 3DPoly Arc AttributeRef Circle DimAligned DimAngular Line PolyLine Figure 5: The AutoCad Object Model. The Application object is the root object for the AutoCad ActiveX Automation Object Model. From the Application

object, a user can access any of the other objects, or the properties or methods assigned to any object. The Document object, which is actually the current AutoCad drawing, provides access to all the graphical and non-graphical AutoCad objects. These objects are grouped as collections, which allow for easy ordering and processing. The ModelSpace and PaperSpace collections contain all the graphical objects found in the drawing's model and paper space. The non-graphical named objects are found in like-named collections, which also have methods and properties for adding, extracting and counting items in each collection. Each object has associated properties and methods. Properties describe aspects of the individual object, while methods are actions that can be performed on the individual object. Once an object is created, the user can query and edit the object through its properties and methods. For example, a Circle object has the Radius property. To get the radius of the circle, the user can simply query this property to get the value. SelectionSet collection is the collection of all selection sets in the current drawing. SelectionSet is a group of one or more AutoCad objects specified for processing as a single unit. The user can use methods such as SelectAll and SelectOnScreen to get a selected object from an AutoCad drawing. Graphical objects, also known as entities, are the visible objects (lines, circles, arcs and so forth) that make up a drawing. The user can use methods or query properties of the object itself to obtain information about it. The common properties of graphical objects are the EntityName, EntityType and Handle properties. The EntityName is equivalent to the class name of the object, e.g. line, polyline, solid. The EntityType property is a numerical equivalent that can also be used to distinguish between entity types. The Handle is a unique object identifier and is persistent in a drawing for the lifetime of the object. Graphical objects also have specific properties, depending on their object types. For example, a line has StartPoint and EndPoint properties, a circle has CenterPoint and Radius properties, and a 3DSolid has a Volume property. By using these properties, the user can get a part's manufacturing information. 5 LINK DEVELOPMENT The link software interfaces AutoCad to the Cost Estimator, as described in Section 2. As outlined above, COM/OLE interfaces allow communication between AutoCad and the link software, even though they are written in different computer languages. C++ Builder provides access to the Windows Application Program Interface (API) functions that are used in these cases. OLE functions such as GetActiveObject, CreateOleObject and OLEProperty were used. With the appropriate arguments, these functions can access the AutoCad Automation object. The arguments of the OLE functions are often of the "variant" type. This type is encapsulated in the "Variant" class in C++ Builder. The variant type is capable of representing values that change type dynamically; in other words it can assume values of differing types at run-time. The variant type is most commonly used in situations where the actual type to be operated upon changes or is unknown at compile-time. Variants can represent different objects in AutoCad, such as the AutoCad Application, Document and ModelSpace objects, etc. The link software can use the methods and properties of these objects directly to get the geometrical information from the AutoCad drawing. A C++ Builder code fragment that can be used to obtain access to AutoCad objects is given below: Variant CADApp,CADDoc,CADDrawing; CADApp=GetActiveOleObject("AutoCAD.Application"); CADDoc=CADApp.OlePropertyGet("ActiveDocument"); CADDrawing=CADDoc.OlePropertyGet("ModelSpace"); The link software has two modes of operation, i.e. Select Mode and Update Mode. Select Mode This mode is used to: Identify the appropriate geometrical information from an AutoCad drawing through user interaction. Transfer the information to the Cost Estimator so that it can calculate the manufacturing cost. Save the information in a link database. Figure 6 shows the user interface of the Select Mode. Two options for selection are provided. For the "Direct Select" option, the user must select a single entity that has a property corresponding to the geometric information required by the Cost Estimator (e.g. the Radius of a Circle). The link software queries the EntityType property to determine how the required information can be extracted from the entity's properties. The geometrical information and the Handle property of the entities involved are saved in the link database. The Handle property is required in the Update Mode, as described in the next section. Alternatively, for the "User Define" option, the user may select a number of AutoCad entities and the link software combines the information from these entities to calculate the geometrical information required by the Cost Estimator. The latter information is saved in the link database and is communicated to the Cost Estimator. Figure 6: The Select Mode User Interface. The information associated with the various geometrical entities is shown in Table 1. Note that in some cases, the Handle property cannot be saved in the link database, as the required information is not associated with a geometrical property of the corresponding entity. An example of such a situation is when a length is indicated by selecting the corners of a solid object. Whether or not the handle can be saved, has a significant influence during Update Mode.

The following C++ Builder code fragment illustrates the operation of Select Mode: CADSet = CADDrawing.OlePropertyGet("SelectionSets"); CADSelect = CADSet.OleFunction("Add","CADSelect"); CADSelect.OleFunction("SelectOnScreen"); int SelectCount = CADSelect.OlePropertyGet("Count"); for(int i=0;i<selectcount;i++) { Variant SelectedObject=CADSelect.OleFunction("Item",i); int SelectedType=SelectedObject.OlePropertyGet("EntityType"); switch (SelectedType ) {... case 8: //Circle CADHandle= SelectedObject.OlePropertyGet("Handle"); String CADprompt = "Get the circle's Radius or Area that this arc contains? R-radius/A-Area: "; String Input=CADUtility.OleFunction("GetString",0,CADprompt); if(input=="r" Input=="R") { double SObRadius; SObRadius = SelectedObject.OlePropertyGet("Radius"); } else if(userinput== "a" UserInput == "A") { SObArea[1][j8]= SelectedObject.OlePropertyGet("Area"); } else { MessageBox(CADWindowHandle,"You didn't select anything","warning",mb_ok); } break;... } } Update Mode To update the cost estimate of a particular part, the designer has to click on an "Update" button in the Cost Estimator. Figure 7 shows the user interface of the Update Mode. Two situations are provided for: Figure 7: The Update Mode User Interface. The first situation occurs when the design has been changed in a way that does not affect the links established in Select Mode. If the required Handle properties were saved during Select Mode, the link software will query the AutoCad drawing, using these Handle properties to get the current properties of the entities. If the properties have not changed, the software takes no further action. If the entities all still exist, the link software allows the designer to accept or reject the update. If it is accepted, the updated values are saved in the link database and transmitted to the Cost Estimator. The second situation occurs: When the entities whose Handle properties were previously recorded in the link database do not exist any more; When the updated values are not accepted by the designer; When the Handle properties were not saved during Select Mode. In this situation, a dialog box similar to the Select Mode dialog (Figure 6) is displayed and the designer must follow a procedure similar to the Select Mode. By using these two modes, the user can easily extract the geometrical information from an AutoCad drawing and use them in the Cost Estimator. 6 SOFTWARE DEVELOPMENT DIFFICULTIES ASSOCIATED WITH USING COM COM technology can bring significant benefits when working with different programming languages. However, the complexity of the COM technology can easily make the software unstable during the development phase. It can even lead to frequent computer crashes or freezes during software development. Some of the crashes or freezes are not repeatable (presumably because the COM server application and the operating system's activities are not controlled by the COM client developer) and are particularly difficult to debug. The use of COM also incurs other limitations in debugging. Integrated Development Environments (IDE's), such as that provided by C++ Builder, do not allow interactive debugging "into" the COM calls. The COM client software developer can therefore not "see" what is happening behind the COM interface of the COM server application. Most of the error messages are generated by the operating system and provide very little useful information for the client software developer. The COM client developer is therefore heavily dependent on the documentation provided by the COM server application developer. 7 CONCLUSIONS The value, in terms of design for manufacturing, of linking CAD software to manufacturing cost estimation software was described. Such a link would be of particular value during the later phases of conceptual design and the early phases of detail design. Since the information in the CAD models will be incomplete during these phases of the design process, the designer has to be involved in establishing the links. This paper describes a link between AutoCad and the Cost Estimator (manufacturing cost estimation software developed by the Department of Mechanical Engineering of the University of Stellenbosch, aimed at simple welded structures manufactured in small quantities). The functions of the Cost Estimator and the usage of COM technology were introduced. The objectives of the link software were also presented. This link was developed in Borland C++ Builder by using COM technology. Two modes are used in the link software: Select Mode and Update Mode. Select Mode is used to prompt the user to pick an object in an AutoCad drawing, calculate the required manufacturing information and communicate this information to the Cost Estimator. Update Mode is used for revising the cost of a changed design and thus to compare the cost of different schemes. The link will substantially reduce the time and effort that the designer has to spend to update the geometry-related information used by the

Cost Estimator after doing design changes in the AutoCad drawing. The case study presented here demonstrates that COM provides usable interface capabilities for a link application of this kind. The authors, however, found that software stability and difficulties in debugging the software are particular challenges. In the future, the link software will be extended to work with Mechanical Desktop. 8 ACKNOWLEDGEMENTS The financial support of the National Research Foundation (NRF grant GUN 2034084) and the Stellenbosch University Research Committee is gratefully acknowledged. 9 REFERENCES [1] Hill, T. M., Bleakman, Earl C., Miles, A., 1994, Knowledge-based integrated design/cost system, Factory 2000-Advanced Automation, No. 398, IEE, pp. 332-337. [2] Peng, T. K., Trappey, A. J. C., 1995, User-friend interface development for CAD-based engineering data management system, Symbiosis of Human and Artefact, pp. 1153-1159. [3] Jayaram, S., Mylebust, A., 1990, Automatic generation of geometry interface between applications programs and CADCAM systems, Computer-Aided Design, Vol. 22, No. 1, pp. 50-56. [4] Bidanda, B., Kandidal, M., Billo, R. E., 1998, Development of an intelligent castability and cost estimation system, Int. J. Prod. Res., Vol. 36, No. 2 1998, pp. 547-568. [5] Leibl, P., Hundal, M., Hoehne, G., 1999, Cost calculation with a feature-based CAD system using modules for calculation, comparison and forecast, Journal of Engineering Design, Vol. 10, No. 1, pp. 93-102. [6] Tsai, J. C., Chang, J. S., 1997, Development of an AutoCad-based geometric tolerancing system, Proceeding of the 1997 ASME Design Engineering. Technical Conf., Sep 14-17, Sacramento, California, DECT97/DAC-3998. [7] Zhao, Y., Ridway, K., 1994, Integrating a knowledge based tool selection system with commercial CAD system, Factory 2000-advanced factory automation, IEEE, Oct 3-5, pp. 182-187. [8] Cottrell, S., Gao, J., 2000, Design for high pressure compressor components using object orientated technology, 2000 Int. CIRP Design Seminar, Haifa, Israel, May 16-18, pp. 289-294. [9] Liu, X. D., 2000, CFACA: component framework for feature-based design and processing planning, Computer-Aided Design, Vol. 32, No. 6, pp. 397-408. [10] Schuster, H. R., 1997, A computer aid for specification development, conceptual design and manufacturing cost estimation in mechanical design, Ph.D.- thesis, University of Stellenbosch, South Africa. [11] Ranse, O., 1997, AutoCAD programming in C and C++, Wiley & Sons Inc., New York. [12] Brockschmidt, K., 1995, Inside OLE, 2 nd Ed, Microsoft Press, Washington. Geometry Information Required by the Cost Estimator Different cases of information generation method Different method to get manufacture information Handle saved Need user define width, height, thickness, length use StartPoint and Endpoint to calculate yes no component that form 3D Solid (such as a line that forms the edge of a box) user defines start point and end point no yes distance distance without line connection user defines start point and end point no yes circle radius property of circle yes no hole diameter blended angle the projected area of regular surface ( such as circle, rectangle, arc) two parallel lines user defines these two lines yes no component of 3D solid user defines start point and end point no yes component of standard entity in AutoCad library (such as standard hole) user defines start point and end point no yes two lines user defines these two lines that form this angle yes no two sections of polyline using the control points of the polyline yes no area of circle and arc area property of circle and arc yes no area of triangle area property of the polyline that forms the triangle yes no area of region area property of region yes no the projected area of nonregular surface area non-regular surface area property of spline that forms the non-regular surface no yes volume volume of 3D solid volume property of 3D solid yes no Table 1: Geometrical Information Required by the Cost Estimator