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.

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.

Stock 1 Process 1

Part 1

Process 2 Process 3

Part 2 Assembly1

Stock 2 Process 6

Problem Assignment

Process 4 Process 7

Project

Project Selection

yes

Process 5

Project exists? no

Assembly2

Project Generation Project Definition Specification Development

Figure 2: Structure of a Project.

Conceptual Design Concept

Embodied Embodied Design Design Proposal 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.

ActiveX Controls

OLE

Linking

In-Place Activation (Visual Editing)

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; Cbased), 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.

OLE Type

Embedding

Information AutoCAD Application

COM Figure 4: COM technology architecture.

3DFace

Preference

ModelSpace Collection

Document

PaperSpace Collection

3DPoly Arc

Block Collection

Block

AttributeRef Circle DimAligned

4.2 Borland C++ Builder and Delphi 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

Dictionaries Collection

Dictionary

DimStyles Collection

DimStyle

Groups Collection

DimAngular

Group

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