機械專業外文翻譯--Pro ENGINEER 軟件二次開發技術

《機械專業外文翻譯--Pro ENGINEER 軟件二次開發技術》由會員分享，可在線閱讀，更多相關《機械專業外文翻譯--Pro ENGINEER 軟件二次開發技術（11頁珍藏版）》請在裝配圖網上搜索。

1、附錄 THE TECHNOLOGY OF THE PROGRAM REDEVELOP ON PRO/ENGIN EER 0　Introduction 　　Pro/ ENGINEER developed by Technology Corporation U SA is CAD / CAE / CAM software system. It integrates 3D solid modeling, designing, machining, analysis and drawing, famous for convenience, parametric feature modeling

2、and system relativity. At present, Pro/ENGINEER has extensive used in various fields in m any countries. Although Pro/E is general utility, it has some shortages in a few facets. Furthermore its design standard differ form our county’s standard. It is an important work to redevelop application

3、to adapt requirement of designer in various fields based on commercial CAD/CAM software platform. Most CAD/ CAM software support interface to redevelop, Pro/TOOLKIT is the redevelopment interface in Pro/E software. 1　Introduction to Pro/TOOLKIT 　　Pro/ TOOLKIT is the customization toolkit for Pro/E

4、NGINEER from Parametric Technology Corporation (PTC). It gives customers and third parties the ability to expand Pro/ENGINEER capabilities by writing programming language code and then seamlessly integrating the resulting application in to Pro/ENGINEER. Pro/TOOLKIT provides a large library of functi

5、ons to provide the external application safe and controlled access to the Pro/ENGINEER database and applications. Pro/TOOLKIT is the PTC application programmer′s interface (A P I). Pro/TOOLKIT uses an object oriented programming style. Data structures for the transfer information between Pro/ENGINE

6、ER and the application are not directly visible to the application. These data structures are accessible only with Pro/TOOLKIT functions. The most basic Pro/TOOLKIT concepts are objects and actions. Each Pro/TOOLKIT library function performs an action on a specific type of object. The Pro/TOOLKIT co

7、nvention for function names is the prefix "Pro" the name of the object type, and the name of the action it performs. A Pro/TOOLKIT object is a well defined and self contained structure used to perform actions relevant to that object. Most objects are items in the Pro/ENGINEER database, such as featu

8、res and surfaces. Others, however, are more abstract or transient, such as the information resulting from a select action. 2　The technology of develop by Pro/TOOLKIT 2. 1　The method of work by Pro/TOOLKIT 2. 1. 1　Synchronous Mode Depending on how your synchronous application from Pro/ENGINEER, y

9、our application can be classified as either "DLL Mode" or "Spawned Mode" The following sectins describe DLL and Spawned synchronous mode. DLL Mode The standard method by which Pro/TOOLKIT application code is integrated in to Pro/ENGINEER is through the use of dynamically linked libraries (DLL s).

10、When you compile your Pro/TOOLKIT application code and link it with the Pro/TOOLKIT library, you create an object library file designed to be linked in to the Pro/ENGINEER executable when Pro/ENGINEER starts up. This method is referred to as "DLL mode." Spawned Mode Pro/TOOLKIT also supports a sec

11、ond method of integration: the "multi process" o r spawned mode. In this mode, the Pro/TOOLKIT application code is compiled and linked to form a separate executable. This executable is designed to be spawned by Pro/ENGINEER and runs as a child process of the Pro/ENGINEER session. In DLL mode, the ex

12、changes between the Pro/TOOLKIT application and Pro/ENGINEER are made through direct function calls. In multi process mode, the same effect is created by an inter process messaging system that simulates direct function calls by passing the information necessary to identify the function and its argum

13、ent values between the two processes. Multi process mode involves more communications overhead than DLL mode, especially when the Pro/TOOLKIT application makes frequent calls to Pro/TOOLKIT library functions, because of the more complex method of implementing those calls. However, it offers the foll

14、owing advantage: it enables you to run the Pro/TOOLKIT application with a source-code debugger without also loading the whole Pro/ENGINEER executable in to the debugger. If you use multi process mode during development of your application to debug more easily, you should switch to DLL mode when you

15、 install the application for your end users because the performance is better in that mode. However, take care to test your application thoroughly in DLL mode before you deliver it. Any programming errors in your application that cause corruption to memory used by Pro/ENGINEER or Pro/TOOLKIT are lik

16、ely to show quite different symptoms in each mode, so new bugs may emerge when you switch to DLL mode. 2. 1. 2　A synchronous Mode DLL and spawned modes are synchronous modes in the sense that the Pro/TOOLKIT application and Pro/ENGINEER do not perform operations concurrently. In spawn mode, each p

17、rocess can send a message to the other to ask for some operation to occur, but each waits for a returning message that reports that the operation is complete. Control alternates between the two processes, one of which is always in a wait state. A synchronous mode is a multi process code in which th

18、e Pro/TOOLKIT application and Pro/ENGINEER can perform concurrent operations. Unlike the synchronous modes, asynchronous mode uses remote procedure calls (.rpc) as the means of communication between the application and Pro/ENGINEER. Simple Asynchronous Mode In asynchronous mode, the application (c

19、ontaining its own main () function) is started independently of Pro/ENGINEER and subsequently either starts or connects to a Pro/ENGINEER process .A simple asynchronous application can spawn and connect to a Pro/ENGINEER process via the function Pro/Engineer Start (). During this startup, Pro/ENGINE

20、ER calls user initialize () if it is present in the application. The Pro/ENGINEER process "listens" for requests from the application and acts on the requests at suitable break points normally between commands. Full Asynchronous Mode In full asynchronous mode, the application implements a control

21、loop that "listens" for messages that arrive from Pro/ENGINEER. As a result, Pro/ENGINEER can call functions in the application, including callback functions for menu buttons and notifications. It is often necessary for your full asynchronous application to be notified of the termination of the Pro/

22、ENGINEER process. In particular, your control loop need not continue to listen for Pro/ENGINEER messages if Pro/ENGINEER is no longer running. In full asynchronous mode must contain a call to the function Pro/Event Process (), which takes no arguments. This function responds to Pro/ENGINEER messages

23、 in a manner similar to synchronous mode. 2. 2　The steps of Developing a Pro/TOOLKIT Application An asynchronous Pro/TOOLKIT application is fundamentally different in its architecture from a synchronous mode application, so we should choose between these methods before writing any application co

24、de. As a general rule, synchronous mode should be the default choice un less there is some unavoidable reason to use asynchronous mode, because the latter mode is more complex to use. 2. 2. 1　Writing application code A Pro/TOOLKIT application must always contain the functions user initialize () an

25、d user CD#3 2〗terminate ( ). These functions have the prefix "user " because they are written by the Pro/TOOLKIT application developer, but they are called from with in Pro/ENGINEER at the start and end of the session. The function user initialize () is called after the Pro/ENGINEER application has

26、been initialized and the Graphics Window has been created. This function should contain any initializations that your Pro/TOOLKIT application needs, including any modification of Pro/ENGINEER menus. The initialization function must return 0 to indicate that the Pro/TOOLKIT application was initialize

27、d successfully. Any other return value will be interpreted as a failure, and the system will notify the Pro/ENGINEER user that the Pro/TOOLKIT application failed. The function user terminate () is called at the end of the Pro/ENGINEER session, after the user selects "Yes" on the Exit confirmation di

28、alog box. Its return type is void. 2. 2. 2　Compiling and Linking a Pro/TOOLKIT Application The compiler options and system libraries needed to compile and link a Pro/TOOLKIT application are generally different on each platform. To ensure that the make file you use for building your Pro/TOOLKIT app

29、lication uses the correct options, you should base your make file on one of the make files located under the Pro/TOOLKIT load point. These are designed for building the various Pro/TOOLKIT applications whose source is included in the Pro/TOOLKIT installation. 2. 2. 3　Registering a Pro/TOOLKIT Appli

30、cation Registering a Pro/TOOLKIT application means providing information to Pro/ENGINEER about the files that form the Pro/TOOLKIT application. To do this, create a small text file, called the Pro/TOOLKIT "registry file," that Pro/ENGINEER will find and read. Pro/ENGINEER searches for the registry

31、file in the following locations, in this order: 1. A file called PROTK.DAT or PRODEV. DAT in the current directory 2. A file named in a "PROTK.DAT", "PRODEVDAT", or "TOOLKIT _ REGISTRY_ FILE" statement in the Pro/ENGINEER configuration file 3. A file called PROTK.DAT or PRODEV. DAT in the directo

32、ry / /text/ 4. A file called PROTK.DAT or PRODEV. DAT in the directory / text in the last two options, the variables are as follows: < Pro/ENGINEER> The Pro/ENGINEER load point (not the Pro/TOOLKIT load point) < MACH IN E> The machine specific subdi

33、rectory (such as sgi_elf2 or i486_nt) < LANGUAGE> The name of the Pro/ENGINEER language the Pro/TOOLKIT application will be used with (such as "Usascii" (English), "German", or "Japanese") The registry file is a simple text file, where each line consists of one of a predefined set of keywords, fol

34、lowed by a value. The standard form of the registry file in DLL mode is as follows: name　　　　 Your Application Name startup dll exec_file ＄LOADDIR/＄MACHINE_TYPE/obj_filename. dll text_dir ＄LOADD IR revision 3 end The statements in the registry file are as

35、follow s: name ——Assigns a unique name to this Pro/TOOLKIT application. This is used to identify the application if there is more than one. Startup—— Specifies the method Pro/ENGINEER should use to communicate with the Pro/TOOLKIT application. This example specifies DLL mode. Exec_ file—— Specifi

36、es the name of the file produced by compiling and linking the Pro/TOOLKIT application. In DLL mode, this is a dynamically linkable library; in multi process mode, it is the executable of a complete program. Text_ dir—— Specifies the directory that contains the menu and message files used by the Pro

37、/TOOLKIT application. These files allow multi language support for menu buttons and messages used in the Pro/TOOLKIT application. Revision——Specifies the version of Pro/TOOLKIT against which you built the application. Use the name for the current release of Pro/TOOLKIT (for example, 2001, 2000i, 20

38、00i2, 2001). End—— Indicates the end of the descript ion of this Pro/TOOLKIT application. 2. 2. 4　Stopping and Restarting a Pro/TOOLKIT Application Pro/TOOLKIT supports the ability to stop and restart a synchronous application with in a single session of Pro/ENGINEER. This is particularly useful

39、during development of an application because it enables you to make changes to your source code and retest it without having to restart Pro/ENGINEER and reload your test models. Use the Auxiliary Applications dialog box to stop and restart applications .To make this option available, the registry fi

40、le (default name PROTK. DAT) should contain one of the following lines: Multi process mode: startup spawn DLL mode: startup DLL If you want to be able to stop and restart your Pro/TOOLKIT application with in Pro/ENGINEER, you must also add the following statement to the definition of the applic

41、ation in the registry file: Allowed stop TRUE If you use the allow stop option, you might also set Pro/ENGINEER to not start the Pro/TOOLKIT application until you explicitly request it. To do this, you must add the following statement in your registry file: delay start TRUE 2. 2. 5　Unlocking a Pr

42、o/TOOLKIT Application Before you distribute your application executable to the end user, you must unlock it. This enables the end user (your customer) to run your application without having Pro/TOOLKIT as an option. To unlock your application, enter the following command: < Pro/ENGINEER>/ bin/prot

43、k unlock file name 3　Conclusions 　　Pro/TOOLKIT application extends the 3D modeling and library of the standard part, and increase some functions of the graphics information′s label, product data management. In this way, we can improve the function of Pro/ENGINEER and accelerate the development of

44、CAD/CAM software. References: [1 ]　Parametric Techno logy Corporation. Pro/TOOLKIT User′s Guide [Z ]. U SA. 2001. [2 ]　LA I Chao2an, L IZhen2nan. The Key Techno logy about Application Development of Pro/E [J ]. computer applications 2001. 9 譯文 Pro/ ENGINEER 軟件二次開發技術 ——李其其格, 武建新, 賀向新 0 簡介 Pr

45、o/ENGINEER是由美國PTC（Parametric Technology Corporation—參數技術公司）開發的CAD/CAM/CAE集成軟件系統。它是集成化的三維實體造型、設計、運動仿真、結構分析、繪制工程圖軟件，特別以方便的參數化特征造型和系統相對性而聞名。目前，Pro/ENGINEER的使用已經延伸到許多國家的各個領域了。 盡管Pro/E是一個一般化的公共程序，但是它在某些方面還是存在一定的不足。此外，它自身的實際標準和我國的國標有所不同。因此，二次開發適應各種不同的領域設計者基于商業的CAD/CAM的軟件平臺的需求的申請是一項很重要的工作。許多CAD/CAM軟件都支持接口

46、的二次開發，Pro/TOOLKIT是Pro/E的二次開發接口。 1 Pro/ TOOLKIT簡介 Pro/E用Pro/ TOOLKIT從美國技術參數公司（PTC）設定工具箱。這使用戶可以通過編寫程序源代碼來提高Pro/E的能力，然后在Pro/E中得心應手地使用產生的申請。Pro/ TOOLKIT提供了一個很大的功能圖書館來保存外部的保存，并控制Pro/E的數據庫的存取以及申請。Pro/ TOOLKIT是PTC程序申請的接口。 Pro/TOOLKIT用一種客觀的定向規畫風格，Pro/E和申請之間傳遞的數據并不是直接可以看的見的，而只能在Pro/TOOLKIT的功能圖書館中存取。最基本的Pr

47、o/TOOLKIT概念就是實體和造型，每一個Pro/TOOLKIT功能圖書館都在一個特殊的實體上運行一個造型。Pro/TOOLKIT功能圖書館中每一個實體都有一個前綴名“Pro”，并用這個名字代表所做的造型，每一個實體都經過定義，并自動連接到相關的實體造型中。大部分實體都存在于Pro/E數據庫中，比如特征和曲面。其他的，都以摘錄或者暫態形式存儲，例如一個造型產生的信息。 2 Pro/TOOLKIT發展的技術 2.1 Pro/TOOLKIT的工作方式 2.1.1 同步模型 根據你如何從Pro/E中申請同步模型，你的申請可以分為“DLL模型”或“Spawned模型”。接下來為您詳細介紹DL

48、L和Spawned同步模型。 DLL模型 把Pro/TOOLKIT申請整合到Pro/E中的標準方法是通過動態地連接到Pro/TOOLKIT圖書館中（DLLs）。在Pro/E運行的時候，當你編譯一個Pro/TOOLKIT文件代碼并將其導入Pro/TOOLKIT圖書館中，你便創建了一個連接到Pro/E運行器中的實體文件。這就是“DLL模型” Spawned模型 Pro/TOOLKIT也支持第二種整合方法：“multi 程序”或者Spawned模型。在這個模型中，Pro/TOOLKIT申請代碼被編譯并連接到一個獨立的運行器中，這個運行器被設計用來形成Pro/E的產物并作為它的一個子程序來運行

49、。在DLL模型中，Pro/TOOLKIT和Pro/E之間的數據轉換是通過直接的功能響應來實現的；而在multi 程序模型中，則是通過一個內部程序信息系統來完成的，這個系統是通過模擬信息在兩個程序中的轉換所必須的功能并通過辨別此功能值來確定功能響應的。Multi 程序模型比DLL模型包含更多的交流信息，特別是當Pro/TOOLKIT更加頻繁地訪問Pro/TOOLKIT圖書館功能的時候，因為實現這些功能響應需要更復雜的方法。然而它有以下幾方面的優點：它可以用一個源代碼糾正直接運行Pro/TOOLKIT而不用下載整個Pro/E糾正運行器。 在你改進你的申請使之更容易糾錯是，如果你用Multi 程序

50、模型，那么在安裝你的終端用戶申請時你必須轉變為DLL模型，因為DLL模型的表現比較好。然而，在你投遞你的申請時，注意在你的DLL模型上徹底地測試。你程序里的任何錯誤都會引起Pro/E使用記錄的亂碼，或者Pro/TOOLKIT會給你一個完全不同的結果，這樣的話，在你轉換你的DLL模型時就會產生新的錯誤了。 2.1.2 非同步模型 DLL模型和Spawned模型都是同步模型，所以Pro/E和Pro/TOOLKIT不會同時產生操作。在Spawned模型中，每一個程序都可以給另一個發送信息來要求某些操作，但是每一個程序都得等待一個操作已經完成的反饋信息才能進行。兩個程序中的控制代理器總有一個通常處

51、于等待狀態。 非同步模型是Pro/TOOLKIT申請和Pro/E可以同時操作的一種復合程序模型。與同步模型不同的是，非同步模型用的是遠程程序呼叫（.rpc），即Pro/TOOLKIT申請和Pro/E可以相互交流。 簡易非同步模型 在非同步模型中，Pro/TOOLKIT申請（包括其自身的main（）動作）是獨立于Pro/E啟動的，然后再啟動或者連接到Pro/E程序中的。一個簡易的非同步模型經由Pro/Engineer Start ()可以產生或者連接到一個Pro/E程序。在這個啟動過程中，如果user initialize ()存在于申請中，那么Pro/E程序就呼叫這個程序。Pro/E程序

52、“聽”來自申請的要求并在適當的休息點對指令之間正常地執行動作。 完全的非同步模型 在完全的非同步模型中，申請實施一個“聽從”來自于Pro/E程序的信息的控制循環，因此，Pro/E程序可以調用申請里的動作，包括收回菜單按鈕和通知的動作。通常，你的完全的非同步申請必須聽從來自Pro/E程序的終止程序。有一種特殊情況就是當Pro/E程序不再運行的時候，你的控制循環就不需要聽從Pro/E程序的命令了。完全的非同步模型必須要有一個無條件呼叫Pro/Event Process ()的動作。這個動作以和同步模型相似的信息反饋方式反饋給Pro/E程序。 2.2 發展一個Pro/TOOLKIT申請

53、的步驟 一個非同步的Pro/TOOLKIT申請在發展步驟上和同步申請基本上是不同的，所以，在寫一個申請代碼之前，我們必須先考慮好用適當的方法。通常有一條規則，同步模型必須預先選擇，除非有不可避免的原因才選擇非同步模型，因為后者使用起來很復雜。 2.2.1編寫申請代碼 一個Pro/TOOLKIT申請必須包含user initialize () 和 user CD#terminate ( )兩個動作，這些動作都有一個前綴“user”，因為它們都是由Pro/TOOLKIT申請擴展器編寫的，但是它們分別在Pro/E的啟動和關閉期間被呼叫。user initialize ()是在Pro/E申請設定

54、并且圖形窗口也創建之后才能使用的，這個動作必須包含任何Pro/TOOLKIT所需要的以及Pro/E菜單修改的設定初值，這個設定初值必須回零來指出Pro/TOOLKIT的初值設定成功。任何其他初值都會被認為是一個錯誤，系統就會通知Pro/E用戶Pro/TOOLKIT申請失敗。user CD#terminate ( )是在Pro/E關閉的時候，在用戶選擇證實退出對話框“Yes”之后被呼叫的，它的回行類型是空的。 2.2.2 編譯和連接一個Pro/TOOLKIT申請 編譯者的選擇和系統圖書館需要的編譯和連接的Pro/TOOLKIT申請在各自的平臺上是不同的。為了保證你用來建立Pro/TOOLKI

55、T申請的文件使用正確的選擇，你必須使你的建立文件基于一個Pro/TOOLKIT建立文件的下載點上，這些文件是設計用來建立各種基于包括Pro/TOOLKIT安裝來源的Pro/TOOLKIT申請。 2.2.3 登記一個Pro/TOOLKIT申請 登記一個Pro/TOOLKIT申請就是提供來自Pro/TOOLKIT申請文件的信息到Pro/E上。為此，我們要先創建一個名為Pro/TOOLKIT“登記文件”的文本文件，使得Pro/E可以找到和讀取。Pro/E在以下位置搜索該登記文件，并通過如下順序： 1 在當前目錄下尋找PROTK. DAT 或者 PRODEV. DAT的文件 2 在Pro/E的

56、結構文件中，一個以"PROTK.DAT " , "PRODEVDA T " , 或者 "TOOLKIT _ REGISTRY_ FILE"命名的報表文件 3 在目錄< Pro/ENGINEER> /< MACHINE> /text/< LANGUAGE>下名為PROTK. DAT 或者 PRODEV. DAT的文件 4在目錄< Pro/ENGINEER> /< MACHINE> /text下名為PROTK. DAT 或者 PRODEV. DAT的文件 后兩者中的變量如下： < Pro/ENGINEER>是Pro/ENGINEER負荷點（而不是Pro/TOOLKIT負荷點） < MAC

57、HINE>機器制造的特性子目錄（例如sgi_elf2 or i486_ nt） < LANGUAGE>Pro/TOOLKIT申請所用的Pro/E語言（比如英語、德語或者日語） 登記文件是一個簡單的文本文件，每一行都由預先定義的關鍵詞組成，然后寫入變量值 名字 你的申請的名字 啟動方式 DLL 管理文件 LOADDIR/＄MACHINE_TYPE/obj_filename. dll 文本DIR LOADDIR 校驗次數 3 回車（結束） 登記文件里的變量稱述如下： 文件名——為你的Pro

58、/TOOLKIT申請分配一個單一的文件名，這是為了確定你的申請是獨一無二的。 啟動模式——選擇Pro/ENGINEER和Pro/TOOLKIT申請信息交流的方式，本例選擇DLL模式 Exec_ file（管理文件）——選擇由編譯和連接到Pro/TOOLKIT申請所產生的文件名，在DLL模型中是一個動態的可連接的圖書館，而在Multi程序模型中則是一個完整程序的運行器 Text_ dir——Pro/TOOLKIT申請所用的包括目錄和信息文件的目錄，這些文件使Multi文件支持Pro/TOOLKIT申請所用的目錄和信息文件 校驗次數——選擇相對于你所建立的Pro/TOOLKIT申請的版本，

59、使用你當前所用的Pro/TOOLKIT申請的版本的名字（例如2001、2000i、2000） 回車（結束）——指出所用的Pro/TOOLKIT申請的結束。 2.2.4 停止并重新啟動一個新的Pro/TOOLKIT申請 Pro/TOOLKIT支持在Pro/ENGINEER單一期間中停止和重新啟動一個同步模型申請，在建立一個申請時，這是非常有用的，因為這讓你可以不需要重新啟動Pro/ENGINEER以及重新下載你的模型測試就直接改變申請源代碼并進行測試，可使用非同步模型對話框來停止和重新啟動申請。 為了得到這個選項，登記文件（失敗文件名為PRODK.DAT）必須包含以下幾條的其中一條：

60、Multi程序模式：重起spawm DLL模型：重起DLL 如果你想在Pro/ENGINEER中停止和重起你的Pro/TOOLKIT申請，你必須在你的登記文件的定義中加入以下的條件： 允許停止“TRUE” 如果你用了允許停止選項，你也可以在不啟動Pro/TOOLKIT申請時啟動Pro/ENGINEER直到你明確地提出了你的申請。為此，你必須把以下條件加入你的登記文件 延遲啟動“TRUE” 2.2.5 開啟一個Pro/TOOLKIT申請 在你分配你的申請運行器到終端用戶之前，你必須啟動Pro/TOOLKIT申請，這使得你的終端用戶（你的顧客）在運行申請之前選擇啟不啟動Pro/TOOLKIT。輸入以下命令來啟動你的申請：< Pro/ENGINEER>/ bin/protk unlock file name 3 結論 Pro/TOOLKIT擴充了3D模型和標準零件庫，也增加了一些圖形信息分類的功能以及產品數據管理，從而，我們可以提高Pro/ENGINEER的功能并加速CAD/CAM軟件的發展。 參考文獻 [1]PTC用戶指導.[Z].U.S.A.2001 [2]賴超安、李震南.關于Pro/E二次開發的主要技術.[J].計算機申請.2001.9.