Fall 2006

In this issue, we have more great stories from the World Event held this summer. Larry Pitts reprises his award-winning presentation in the cover story, while Ron Watson talks about the use of PTC tools and the importance of the Product Development System at ITT. We also have a few new tips and tricks for your reading pleasure. Due to unexpected circumstances, a couple stories planned for this issue did not make it; we hope to have them available for January. Best Regards,

Work/Life Balance: Making the Most of Regeneration Time by Larry Pitts, PlugPower

Rick Snider, Publisher, Profiles Magazine

ITT's Global Vault–Realizing the Value of PDS by Ronald Watson, ITT

Regional User Group Calendar

Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids by Rich Becher, Carrier Corporation

Download a PDF of this issue Copyright 2006 PTC/USER, Inc. All rights reserved.

Exceptional Pro/INTRALINK Scripting–And How to Avoid It by Marc Mettes Pro/ENGINEER Wildfire 2.0 Makes BOM Balloons in a Jiffy by Florin Neamtu, Belcan Corporation

Animate Flexible Components with Regemination by Toua Vang, Guidant Corporation

Work/Life Balance: Making the Most of Regeneration Time By Larry Pitts, PlugPower

If you’re like me, you’re getting sick of all these “best practice” and “CAD standards” articles littering our favorite design magazines. Everyone is so concerned with making robust Pro/ENGINEER models that regenerate flawlessly and efficiently. There seems to be a written procedure for every keystroke and mouse-click a Pro/ USER could make.

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

To this I say, “Standards shmandards.” It’s time to have more fun at work. All you have to do is learn the fine art of regenersurfing. What is this new technique? Well, let’s see what Webster says… regenersurfing (rê·jen·er·sir·fin). The act of creating long CAD software regeneration cycles with the intent of browsing the World Wide Web while "waiting." Think about it. What could be better than casually surfing the Internet while giving the illusion that you’re doing something constructive? Your boss thinks you’re intensely working on some complex assembly when you’ve actually spent your day poking around the likes of eBay and NFL.com. Luckily for you, I’ve spent years perfecting this art and I’m going to share that experience with you. The key to regenersurfing is employing design methods that confuse Pro/ENGINEER. So, just for you, I’ve assembled a list of surefire ways to slow down regeneration time and speed up your surfing performance.

Tip #1. Spin and leave dimensioning. If you were in a hurry, which of the following two equations would you rather solve?

.50/.125 or .4999987/.1250012

If you picked the second one, you’re either a glutton for punishment or a math geek with lots of time to kill. You may be thinking to yourself, “This is a computer calculating the answer, not a human brain.” You’re right; computers are extremely fast. But consider the massive amount of calculating Pro/ENGINEER has to do to make a slightly complicated feature. These equations add up and can really take a toll on your regeneration speed, especially when combined with a wacky accuracy setting. So the next time you’re in sketcher mode, instead of typing in an easily divisible threedigit value, grab the modify dimension wheel and give it a whirl. For extra fun, I like to take it out to seven decimal places and embed a friend’s phone number into sketch dimensions. For example, .8675309 would be perfect if you have a friend named Jenny.

Tip #2. Circle the wagons with circular references.

Have you ever heard the statement, “You can't be your own mother…if you manipulate time, you might accidentally disappear”? In biology, that claim holds true for just about every life form except amoeba and other one-cell protozoa. Fortunately for those wanting to expand Pro/ENGINEER regeneration time, a component can be its own parent with a little performance-killing

blunder known as the circular reference. A circular reference typically results when you redefine a feature’s or component's references to another feature or component that was created after it. In other words, it‘s a confused parent-child relationship. When regenerating the assembly, Pro/ENGINEER has to loop around redundantly to confirm placement. It’s the CAD world’s version of the chicken-and-egg problem. Of course, understanding what a circular reference is, is one thing. Knowing how to make them is another. Here are a couple dependable ways to create an assembly Woody Allen would be proud of. (2a) Pick at will. Model tree confusion is key to slow regeneration, so you want to reference as much unrelated geometry as possible. When working in an assembly, keep the parent-child relationship in mind. Drive intent from peer objects at different levels in the assembly structure without using logical shared geometry features such as External Copy Geometry. The beautiful thing here is that you don’t have to try to make a circular reference. It’s easy. Just let your mouse run amuck, and before you know it, you’ll have a nice long .crc file. Don’t forget: the more loops in a circular reference the better. Try to make the components involved in the problem the parents of as many child components as you can. Don’t be afraid to go up and down a few assembly levels. Eventually your model tree will resemble a bowl of spaghetti, and you will be on your way to bringing Pro/ ENGINEER to a standstill. (2b) Restructure recklessly. Another way to create circular references is by carelessly using the Restructure tool. While not a consistent performance-killer, restructuring can really mess things up if used improperly. First, you can easily create unintended external references if you don’t pay attention to the selection query. It’s simple to lose track of what’s related to what. Later, when you change something, KABOOM!!! The assembly becomes unstable. Second, you can get references "climbing up the tree" and forming all kinds of bottomup relationships that slow down regeneration. With a bottom-up model structure, the system may need entire assemblies in session that it would not otherwise need. This can cause problems for users trying to work concurrently on models. It can also end up monopolizing top-level assemblies, and even cause problems with Pro/INTRALINK in the form of circular dependencies. Use this technique to really undermine top-down design practice.

Tip #3. Sweat the small stuff. Features like helical sweeps, used to make threads, extruded text, and advanced rounds, are good for representing visual aspects of a design. As a result, most designers will either make a simplified rep to remove the features from memory or use a cosmetic representation such as curves. These features are your special friends because they take a really long time to regenerate. Since you’re trying to decrease performance efficiency, it’s good idea to model these unneeded features as often as possible. In one brilliant application of this technique, I saw a salty old regenersurfer model woven screen mesh.

Tip #4. Leave your mark.

Last but not least, take the time to let people know this is your mess. Put your personal touch on your parts. Leave old features such as shared data, unused datums, and other garbage in your models. Go ahead and be a pack-rat. Leave old ideas in the form of suppressed features and components. One of the most effective techniques you can use is to hide buried features inside of other features. For example, model a helical sweep normal to a complicated datum curve and then make sure it’s completely encompassed in the body of your part. Although most of these efforts won’t show up in your graphics window, they are working hard behind the scene to really bring down regeneration speed.

Reality Check You’ve probably realized by now that this is all a joke. Call it what you will—engineering satire, design comedy, or nerd humor—laughter may be the one thing that gets you through another day of failure resolution and corrective tolerance stack-ups. Like anything else in life, these tribulations can actually be entertaining if you lighten things up with humor. The fact is, Pro/ENGINEER users can develop bad habits that drive their colleagues crazy. They may cut corners when faced with an impending deadline, or display a complete disregard for standards. The impact of these bad design practices becomes crystal clear when you introduce the ridiculous idea of intentionally messing things up. But if you don’t think this is funny, you may be in need of more help than you know. Think of this as an intervention. Just have an open mind and ask yourself, “Do I do this?” If the answer is yes, you’re probably causing more problems than you realize.

Larry Pitts is a design engineer at Plug Power Fuel Cell Company, where he has worked with PTC products such as Pro/ENGINEER, Pro/ INTRALINK, PDMLink and Pro/MECHANICA since 1998. Larry has spearheaded using data-sharing techniques to generate robust, complex parts that require frequent design change. He is also a advocate for user education and participates on the CAD Steering Committee. This article is based on his award-winning presentation at the PTC/USER World Event 2006. You can find more of Larry’s humor at www.baddesign.us.

ITT's Global Vault–Realizing the Value of PDS By Ronald Watson, ITT When you hear the term “Product Development System” (PDS), you might think it's just a cool PTC marketing slogan. When you take the time to learn more about it, you might realize that it's a fundamental requirement for operating today's global businesses. At ITT Corporation, we decided to embrace PTC's Product Development System concept in 1998 and its current form in 2004, adopting the parts that are most applicable to our business needs. This was the beginning of an interesting and often exciting journey that many of today's organizations are contemplating or have already embarked upon. While not without problems and setbacks, creating a PDS has had huge payoffs for our customers, supplies, and employees alike. ITT is a global, multi-industry company with primary businesses in the areas of defense electronics and services, fluid technology, and motion and flow control. In 2005, ITT employed 44,000 people in hundreds of offices around the world, most of them outside North America. The enterprise comprises three management companies. Within each of these companies are “Value Centers” or groups that develop, create, and manufacture products for a specific market segment.

A Little Bit of History Our PDS initiative built on the progress we had already achieved in creating “singlesource data”—a common, integrated set of product information required to support our corporate strategy to “Design anywhere. Build anywhere. Sell, service and integrate everywhere.” ITT first articulated its strategic vision in the early 1990s, well before the infrastructure was in place to support such an ambitious information strategy. To maximize the tools available at the time, we in large part made our businesses and business processes ERPcentric and used email as both a workflow and content management tool. When 2000 rolled around, we attempted to leverage various connectors for email, ERP and the internet. Unfortunately, the information that was such a cornerstone for our efforts generally remained hidden. The lack of true workflow and knowledge management tools and platforms made it difficult to demonstrate the value of singlesource data and get the necessary buy-in from businesses and users. In 2001, new "spaces" like the Collaborative Commerce Model (CPC), driven by the dotcom boom, came into play. Although short-lived, this proved to be an important milestone because industry as a whole was beginning to accept the product data strategy that ITT was championing. To us, CPC was based on core processes (product development, demand creation, order acquisition, etc.), which in turn were built on basic infrastructure processes (business-to-business, business-to-consumer, network

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

management, etc.) and managed with governing processes (strategic planning, capital allocation, budgeting, etc.) The glue holding it all together was connectivity and free information flow across the enterprise. The key concept here is that technology is the enabler and process redesign the foundation.

Figure 1. End Point Vision Diagram

Single-Source Data In business today, information is a valuable asset. Information lying dormant or unreachable is as costly as excess inventory sitting on a shelf in a forgotten warehouse. An information infrastructure that enables the enterprise to "Design anywhere. Build anywhere. Sell, service and integrate everywhere.” must therefore start with digital data repositories for customer, vendor, supplier, OEM and internal product information. To accomplish this, we needed to standardize on a common set of master tools that define our “product” interface for all transactions while leveraging a shared knowledge base without translation. By minimizing translations and hence errors (defects), we improve quality and customer satisfaction, as well as reduce overall costs and the need to rework. Furthermore, using an integrated set of tools from design to aftermarket also improves data integrity and enables design re-use, common sourcing, and common part numbers, components and materials. Common tools facilitate the standardization of Value Centers with common processes. At the same time, the Value Centers can leverage each other's data while automating processes where possible and where it makes the most sense. Again, this prevents defects and shortens cycle time as we integrate various disparate systems. We have also realized real cost savings by negotiating with a single vendor as a corporation vs. individual businesses working with select suppliers. Moreover, common sense and experience taught us that integration of data is more efficient when standardized with common formats. There are also the added benefits that knowledge can easily be shared amoung users of common tools.

The most important payoff, however, is that this approach helps us extract additional value out of our internal manufacturing capabilities, while at the same time leveraging our significant capital investments. In addition, single-source data and a common data platform allow us to ● ● ● ●

meet continuous process improvement goals (VBSS – Value Based Six Sigma) meet our organic growth goals (VBPD – Value Based Product Development) improve asset utilization across the enterprise, and implement e-commerce initiatives.

The Tools 1. Pro/ENGINEER Standardizing on Pro/ENGINEER laid the foundation for our product data strategy. As most of you know, Pro/E is a parametric, feature-based, fully associative database that is platform-independent. This powerful software provides a variety of capabilities for engineering our products by creating detailed solid and sheet metal components, building assemblies, producing fully documented production drawings and photorealistic images, and manufacturing models—all in virtual 3D space. The key reason why we chose Pro/E over competitors is that it is based on a single, integrated data model. We are not a software company and programming interfaces between various software companies' solutions is something we do only without choice. Reducing the integration between various functions was a priority, and PTC had already done this for us in the area of mechanical design software. 2. Pro/INTRALINK One of the first steps was to implement Pro/INTRALINK at each major business location. Back in 1999, this was the best technological solution available for managing complex product data like Pro/ENGINEER files. Based on our strategy and vision, we made the decision not to use Pro/INTRALINK to manage all product data because of our expectations for Windchill (with which we had no experience at the time) and concerns it would make upgrades and eventual migration to Windchill much more problematic. The former Engineered Products Solutions Group (EPSG), which was already developing products collaboratively using manual methods, was chosen as the first multi-site Pro/INTRALINK implementation. These sites were manufacturing the same product to meet both US and EU standards. To expand colloboration outside a few multi-site servers, users manually pointed a Pro/INTRALINK client at a different remote server. While employees could thus collaborate beyond normal boundaries, this approach was still not optimal.

Figure 2. Pro/INTRALINK Topology (circa 99'-02) diagram It didn't take long before the limitations of this form of enterprise collaboration became obvious. As the EPSG businesses expanded and products were shifted to different design and manufacturing sites, the stress on users increased dramatically. They had to be constantly aware of where to locate the data, how to manage it while working on it, and where to put it back when finished. What we faced were lots of Pro/INTRALINK systems doing a great job at managing Pro/ E data but unable to handle global needs. ITT had implemented PTC's ProjectLink in 2001 to help support our collaboration and program/project management.

Figure 3. Pro/INTRALINK Topology (circa 02-04) 3. Windchill In early 2001, ITT was the first company to complete a production implementation of ProjectLink. In 2002, after a series of successful exploratory pilots, we followed this up with our first production implementation of a Windchill Foundation-based system for our global engineering change system, along with other supporting processes. As PTC listened to feedback from us and other customers, it became clear that we needed a set of preconfigured, integrated applications to reduce the cost and time of implementation. We needed out-of-the-box functionality that addressed real business needs. The result was the expansion of the “Link” applications, including PDMLink. Fast forward to 2004, our worldwide team selected PDMLink and ProjectLink as the base components of what we call the Global Vault. We envisioned this as a platform that would meet our needs in three main areas—Vaulting (Search, View and Markup), Enterprise Change Processes (Graphical Workflow and Lifecycle Management), and PDM (Pro/ENGINEER Data Management). The Global Vault would eventually replace ProjectLink as a standalone application, Windchill Foundation, all of our Pro/INTRALINK 3.x servers, and legacy systems such as Access databases, shared network drives, etc.

Global Vault as Platform The Global Vault has four major components: create (Pro/ENGINEER), collaborate (ProjectLink), control (PDMLink), and communicate (Arbortext). 1. Create. ITT has millions of pieces of Pro/ENGINEER data dating back to the late 1990s. Although it is easy to focus on the cost of a particular CAD system, the real value is in the data. As such, data created in Pro/ENGINEER Release 5 in 1990 is still accessible in Wildfire 2.0 in 2006. Not every CAD system can make that claim. Standardization on a single CAD system from concept through design and manufacturing has clear advantages. The fewer systems used to create data, the better because it significantly reduces translations, which in turn reduces errors and enables more streamlined processes. (This is as true for a word processing system as for a CAD system.) 2. Collaborate . We now use an integrated ProjectLink as part of the PDMLink environment, right out of the box. We also leave a great amount of flexibility to the project creators/managers and end users for how it is used. The rule is that ProjectLink should be used for all collaboration and projects related to product data. Other collaboration tools, such as our ITT portal, are for collaboration and projects related to non-product data. 3. Control. Rather than some uber-ruler that controls everything, the Global Vault integrates with systems that are channels to the intranet, internet and extranet. The Global Vault is focused on controlling, managing, sharing—through the use of document management, workflow, lifecycle management—all product data. Internally, there are still business and other systems geared to specific purposes that may either obtain information from or provide information to the Global Vault. 4. Communicate . At ITT, documentation is sometimes as critical as the product or

service itself. Efficiently and accurately providing this information, in different formats and channels, is currently a costly and time-consuming process. In some cases, communicating too much is not always a good thing. For example, a user guide that is delivered with an engineered product that details options that are not included in the “As Shipped” configuration can confuse the customer and result in a less than optimal experience.

Focus on Need We have boiled the requirements for the Global Vault down to three specific needs: ● ● ●

Share product information globally Share product information securely Create a single source of product information

These criteria are the first gate a concept must pass before it becomes a project. For instance, if a team comes forward wanting to access information in the Global Vault for the purpose of dumping it into a website with no access controls, the request would be summarily rejected. It is important to note that these are needs. The functions around consuming, sharing and accessing the information are different for specific businesses, suppliers or customers.

Making the Vault Truly Global “Communicate” is the latest capability added to our product development system. Introduced by our largest Value Center, ITT Flygt, the Arbortext global enterprise publishing project may be the most important initiative at ITT today. Dynamic publishing can be likened to mass production of documents from a common database of discrete components.

Figure 4. PTC PDS schematic for products, the ones shown are in production or are in the advanced implementation phases.

Why enterprise publishing? Well, think about it like an engineer. What if every Pro/ ENGINEER assembly was made up of features in one big part file (like when you import an IGES or STEP file into Pro/E from another CAD system). How difficult would it be to find, let alone re-use, a set of geometric features? Could you operate efficiently with Pro/ E if that was a process you had to follow? The question, then, is why accept this as business as usual in our everyday documentation processes?

Figures 5a, b, c. ProE Model 1, 2 and 3 In the traditional publishing process, each author creates and manages both the format and the content. The content is transferred manually into different publications and documents using email, cut and paste, etc. These documents are in turn converted to different media, such as high-resolution PDFs for print and HTML for the web, to communicate through different channels. Under this system, technical writers spend hours updating hundreds of individual documents every time engineers make minor changes to a component used in different products. Authors also spend a lot of time searching for things they had written or translated, and half of the time their searches are unsuccessful.

Figure 6. Independent Publication Process With Arbortext, in contrast, discrete “blocks” of standard information are mapped to different document types and formats, including websites, CD-ROMs, PDFs and wireless devices. The assembled information is automatically formatted to suit the needs of the channel. Now, making a change is much simpler because it affects only one single block of information.

Figure 7. Single Publication Cycle

Automatic updating of the parts list is one of the first dynamic publishing applications to go live, providing an immediate savings of some 2,000 man-hours a year. The parts list is now configured and updated by retrieving the part numbers and descriptions from the mainframe, the exploded view of the assembly from the CAD system, and a short explanation typed into a web application and stored for reuse.

Figure 8. Arbortext Linking Documents The ITT Flygt project has expanded into a Fluid Technology Management Company project with all four Value Centers (Flygt, RCW, IBG and AWT) working collaboratively. Arbortext will ultimately integrate a translation memory database with the Windchill PDMLink component of our Global Vault, which will constantly “learn” from previous versions and allow a very selective update when the basic text is changed. This will save an enormous amount of time and money because it means that information will be translated just once and again only when changes are introduced. But this is only the tip of the “benefits iceberg” from using the Arbortext software. Once our dynamic publishing system is fully implemented, more and more of our documents will be generated and updated automatically. At that point, our technical documentation will be accurate and up to date, more accessible and user-friendly, and presented with a consistent ITT look and feel.

What's in Store? Is the system perfect? No. Are there issues? Yes. Implementing a Product Development System is tough both procedurally and technologically, not to mention culturally. The good news is we learn from every problem and we continue to make it better. Even if the challenges sometimes seem insurmountable, the value that PDS brings to a global enterprise is many orders of magnitude greater.

You have heard the saying, “Life is not a destination, it's a journey.” Well, there's still a long road ahead with many more obstacles to overcome before we have a fully functioning product development system. But when we look at how far we've come, we are more committed than ever to face whatever challenges lie ahead.

Figure 9. Global Vault Data Process Design Ron Watson is global product data manager at ITT Corporation and a member of the PTC/USER Board of Directors. This article is based on his keynote presentation at the PTC/USER World Event 2006. Click here for the author's email address

Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids By Rich Becher, Carrier Corporation

There are many ways to automate time-consuming tasks within the Pro/ENGINEER environment. The approaches that seem to work best, however, are simple, to the point, and get the job done without a 100-page training guide. Creating a "Wizard"-type interface meets all these criteria and can be easily adopted by your Pro/ENGINEER community…and even by users with no Pro/ENGINEER knowledge. A Wizard UI is so easy to use that it virtually eliminates the need for training. And in certain cases, Pro/ENGINEER Wizards can be used as an alternative to customized Pro/TOOLKIT apps. In the example presented here, a Wizard UI leverages Pro/ENGINEER macros accessing MS-DOS batch scripts automating the creation of sheetmetal flat patterns.

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

The 1-2-3 of Wizardry

1. Pro/ENGINEER Mapkey The process starts out with a simple Pro/ENGINEER macro. In this case, the macro accesses or “calls” a MS-DOS batch script. To create this macro, select the OS Script tab from the Record Mapkey dialog. Enter the required information and save the mapkey.

The resulting Pro/ENGINEER mapkey should look like this:

mapkey wiz-start-template @MAPKEY_LABELStart Template Wizard;\ mapkey(continued) %wiz-lc-reset;\ mapkey(continued) @SYSTEMcall \%pro_proj_dir\%\\wizards\ \StartTemplates\\bin\\wiz.bat;\ mapkey(continued) %wiz-lc;%wiz-template;\ mapkey(continued) @SYSTEMrmdir /q /s \%ProEWizClienTmp\%;

Note the additional syntax for the OS command “@SYSTEM” as well as the “\” around the paths.

2. MS-DOS Batch Batch scripting is not a complex "programming language" and is inherent to any Windows (2000/XP) platform. Batch scripts require NO compiling and will run on any Windows client without any special software or configuration. In this step, you define the types of questions to ask the end user via a MS-DOS batch script. The script processes the user input and programming logic then determines additional questions to ask until all required user input is gathered and processed.

3. Wizard UI The Wizard UI used for these examples uses freeware called Wizard’s Apprentice or WizApp (available at http://wizapp.sourceforge.net). This self-contained, executable Visual Basic app allows you to ask questions from a MS-DOS batch script file using Windows dialog boxes in the so-called Wizard style—large dialogs asking one question at a time, with a Back button, a Next button and a Cancel button. In the sample below, WizApp provides an UI asking which Wall Type to use as the first feature for a sheetmetal part. Once all questions have been answered, a Pro/ENGINEER mapkey is created on the fly and executed in Pro/ENGINEER, creating the sheetmetal part per the user’s input.

Sample Start Templates Wizard

Sample Pro/ENGINEER Wizards

Start Templates. Leverage company standard templates. tubeEZRouter. Prompts end user for Start and End points of copper tubing design using Pro/PIPING module. Creates tube part and drawing including Bend Table. Sheetmetal Flat Generator. Creates DXF or IGES flat pattern of a sheetmetal part.

Auto email including resulting DXFs in a ZIP file. Can run in no-graphic mode. Blank Size. Calculates XYZ envelope of any part (i.e., sheetmetal flat blank size) PDF2DXF. Converts any PDF to DXF. Uses Ghostscript and GSView freeware (available at http://www.cs.wisc.edu/~ghost/). File Zipper. Creates ZIP file of current object and saves to hard drive. PDF Batch. Batch processes PDF creation of drawings, layouts, reports, parts and assemblies. Can batch process an entire Pro/INTRALINK Workspace as well as an entire folder when working outside of Pro/INTRALINK (i.e., stand-alone Pro/ ENGINEER).

Maintenance Tip Maintaining Pro/ENGINEER Wizards typically means updating any Pro/ENGINEER mapkeys that are due to UI changes in Pro/ENGINEER.

Rich Becher is a mechanical engineer in the Engineering Information Systems division of Carrier Corporation. Click here for the author's email address

Exceptional Pro/INTRALINK Scripting–and How to Avoid It By Marc Mettes

If you've attempted any complex Pro/INTRALINK scripting applications, you're already aware that if a result is not expected, the whole script stops. Examples of this behavior are the message box that appears after running a BOM report on an empty assembly, a family table report on a non-family table object, or a relationship report on an object with no relationships.

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

The good news is that these "error" messages are actually unhandled Java exceptions. If your script properly handles these exceptions, it can continue—allowing it to make important decisions about what to do next at runtime.

Handling the Exceptions To handle exceptions thrown by Pro/INTRALINK scripting methods, you need to use something like the following code:

try { IL.someMethod(...); }

catch (Exception e) { doSomethingHere(...); } finally { alsoDoSomethingHere(...); }

In other words, you try{} a set of one or more methods, then you catch{} any resulting exceptions. After all of that, the optional finally{} block is executed. In most Java applications, you’ll catch multiple types of exceptions with several catch statements. Pro/INTRALINK scripting methods seem to throw only one generic type of exception. Here we should appreciate the designers of the Pro/INTRALINK client Java interface. As a Java application, throwing exceptions is exactly what should be happening. Now if we need to process Commonspace objects, which may or may not exist, we can use exception handling to avoid script crashes. As an example, if you want to take a list of objects from a text file to check out to a workspace, the most reliable way is to Locate the items first and then process the items one by one as they appear in the search results. To do this, we need to know the Name, Branch, Revision, and Version for each object. To read a list of object names from a text file, first create a FileReader object, then enter a while loop to process each object one at a time. The following code will try to open file "input.txt". It will then read each line from the file, which is assumed to be tab-delimited data containing Name, Branch, Revision, and Version. It switches the tab character and replaces it with a slash character to form the "object" string. public void run () throws Exception { String fileName = "input.txt"; BufferedReader br = null; try { br = new BufferedReader(new FileReader( fileName )); } catch (Exception e) { // Print message (shows up in .proi.log file) System.out.println( "Cannot open file: " + fileName );

return; } String line; // read each line from file while ((line = br.readLine()) != null) { // split line into array String obj[] = line.split("\t"); // skip line if not 4 columns of data if (obj.length != 4) { continue; } // change tab to '/' character String objSpec = line.replaceAll("\t", "/"); // Setup named variables for readability String objName = obj[0]; String objBranch = obj[1]; String objRev = obj[2]; String objVer = obj[3]; // do most Intralink stuff here ... } br.close(); // Very helpful to close the file on Windows! } // end of run()

Everything that follows will fit into the “do most Intralink stuff here” section. Now that we have the necessary information in objName, objRev, and objVer, we can start the process.

1. Locate an Object The following code opens a Locate window, adds rules for the search, then performs the search:

// Open Locate Window IL.setActiveWindow( "Locate", null, "Locate" ); // Clear, then Add search criteria IL.clearFilter(

);

IL.addFilter( "Name", "=", objName ); IL.addFilter( "Branch", "=", objBranch ); IL.addFilter( "Revision", "=", objRev ); IL.addFilter( "Version", "=", objVer ); // Performs the locate IL.applyFilter(

);

2. Select an Object Once the Locate has finished, we need to determine via select() if anything was found. The arguments to select(), for both Commonspace and Located objects, are the string “PIV” and then a string of the form "abc.prt/main/A/1" ( Name / Branch / Revision / Version ). If you attempt a select() and no objects or the specific object are not found, an exception will be thrown. If that is not handled, your script is done. To prevent this, the following code will handle the exception. // Select the located object try { IL.select( "PIV", objSpec ); } catch (Exception e) { System.out.println ( "Not found: " + objSpec + "\t" + e. getMessage() ); continue; }

The continue statement allows you to gracefully bail out and move on to the next item at the top of the while loop. The getMessage() method of the exception object (e) returns

the text that would have appeared in the error message box (i.e., “There are no Where Used dependencies for the selected object”). You can use this message if multiple problems can occur for a particular action. If you're searching for Latest Revision and/or Version, this won't really work because you probably won’t know the Revision and/or Version ahead of time. One way to approach this is to use selectAll() to select all of the objects, and then figure out how many were selected. If you locate by a specific Revision/Version or by Latest, only one object should appear in the search results. Here is some code that can handle this situation. try { IL.selectAll( "PIV" ); String selobjs[] = IL.getSelectedObjects("PIV"); if (selobjs.length == 0) { System.out.println( "Not found: " + objName ); continue;

// or some other action ...

} // split selected object string into array String obj_item[] = selobjs[0].split("/"); // Setup named variables for readability objName = obj_item[0]; objBranch = obj_item[1]; objRev = obj_item[2]; objVer = obj_item[3]; System.out.println ( "Found: " + objName + "," + objBranch + "," + objRev + "," + objVer ); } catch (Exception e) { System.out.println ( "Not found: " + objSpec + "\t" + e. getMessage() ); continue; }

Again, the continue statements let you move on to the next item. If you've moved past the if statement, then you've probably made a successful selection of the object and can proceed to the next step.

3. Create a Workspace With an object selected, the next task is to perform a check out. Of course, before we can check out objects, we must have a workspace. In this example, we will create a new workspace for each object processed. String wsName = "test_workspace"; // Create the workspace try { IL.createWorkspace( wsName, "" ); } catch (Exception e) { // Couldn't create workspace, try deleting first try { IL.deleteWorkspace(wsName); IL.createWorkspace( wsName, "" ); } catch (Exception e2) { // Still couldn't create workspace, give up continue; } }

Included is an attempt to delete a workspace of the same name in case the original creation failed. Now you’re ready to perform the check out.

4. Check Out the Object As with the Locate and Workspace creation, a check out can also throw exceptions. For example, exceptions that may come up are family table version conflicts, insufficient authorizations, etc. In this case, a quick way to deal with this is to change the Dependency setting to “All” or “Required.” Here is an example that falls back to “Required” if there's a problem. If this still generates an exception, the problem is probably too complex to automate and you should either move on to the next item or stop altogether. // Checkout the object try { IL.openWindow( "CheckOut", "","" ); IL.setCheckoutMethod( true ); IL.setTargetWorkspace( wsName ); IL.checkout(); } catch (Exception e) { // Caught exception, some problem occurred System.out.println ( "Checkout failed, trying Required" ); try { IL.updateDependents( "Required", "latest", 18 ); IL.checkout(); } catch (Exception e2) { // Caught another exception, some other problem occurred, give up System.out.println( "Checkout still failed, giving up" ); continue; } } IL.closeWindow(); // Hit ok in dialog box

5. Run a Pro/ENGINEER Trail File Now that we have a workspace with our object, we can do something with it. A desired task might be to run a trail file in a Pro/ENGINEER session. Perhaps the best way to deal with trail files is either to generate them ahead of time or on the fly within the Java code itself. If we presume a trail file exists, we can run it like this: // Open workspace window IL.openWindow( "Workspace", wsName, null ); IL.setActiveWindow( "Workspace", wsName, null ); IL.openWindow( "RunProeTrail", "", "" ); boolean withGraphics = true; String trailFile = "trl_print.txt"; // Run trail file try { IL.executeProETrail( wsName, 0, withGraphics, trailFile ); } catch (ILScriptException x) { System.out.println( "Problem when running trail file: " + x. getMessage() ); } IL.cancel(

); // Intralink records this for some reason

Thread.currentThread().sleep(30*1000); // sleep for 30 seconds

The sleep statement helps to alleviate a Windows issue, where the script will continue even though Pro/ENGINEER has not fully started. We need this to delete the workspace when the trail file has completed. Without it, the script will delete the workspace before Pro/ENGINEER gets a chance to see it. (On Unix, the script waits for Pro/ENGINEER, and the sleep statement is mostly unnecessary.) On a side note, I've noticed that when Pro/ENGINEER trail files go out of sequence when started from Pro/INTRALINK 3.3, an exception is not always thrown. Some detection of the end result may therefore be necessary to determine if the trail file session completed successfully.

6. Delete the Workspace Another unfortunate side-effect of running trail files for extended periods (an hour or more) is that the script may continue even though the trail file is not done. This can cause all sorts of grief if you only want to deal with one Pro/ENGINEER session (and one workspace) at a time. The workaround for this problem is to try{} to delete the workspace. If an exception is thrown, the workspace cannot be deleted, which usually means that the trail file is probably not done. If you put the deletion attempt in a loop like this, you’ll know when the trail file has finished: while (true) { try { IL.deleteWorkspace( wsName ); } catch (Exception e) { // Couldn't delete workspace, wait then try again Thread.currentThread().sleep(10*1000); // sleep for 10 seconds continue; } break; // workspace was deleted, exit loop }

Unfortunately, this limits what you can do after the trail file has run, but at least the result is something consistent and reliable. Toward the end of the while loop, you should close the workspace window. If not, you may end up with some extra windows stemming from each time a workspace is used. IL.closeWindow(); // Close Workspace window

If we wrap all of these tasks together, the code in the run() method might look something like the following (the name of the class file is irrelevant). Be sure to include the import statement at the top of the file to ensure that the program compiles. import java.io.*;

public void run () throws Exception { String fileName = "input.txt"; BufferedReader br = null; try { br = new BufferedReader(new FileReader( fileName )); } catch (Exception e) { // Print message (shows up in .proi.log file) System.out.println( "Cannot open file: " + fileName ); return; } String line; // read each line from file while ((line = br.readLine()) != null) { // split line into array String obj[] = line.split("\t"); // skip line if not 4 columns of data if (obj.length != 4) { continue; } // change tab to '/' character String objSpec = line.replaceAll("\t", "/"); // Setup named variables for readability String objName = obj[0]; String objBranch = obj[1]; String objRev = obj[2]; String objVer = obj[3]; // Open Locate Window IL.setActiveWindow( "Locate", null, "Locate" );

// Clear, then Add search criteria IL.clearFilter(

);

IL.addFilter( "Name", "=", objName ); IL.addFilter( "Branch", "=", objBranch ); IL.addFilter( "Revision", "=", objRev ); IL.addFilter( "Version", "=", objVer ); // Performs the locate IL.applyFilter(

);

// Select the located object try { IL.select( "PIV", objSpec ); } catch (Exception e) { System.out.println ( "Not found: " + objSpec + "\t" + e.getMessage() ); continue; } String wsName = "test_workspace"; // Create the workspace try { IL.createWorkspace( wsName, "" ); } catch (Exception e) { // Couldn't create workspace, try deleting first try { IL.deleteWorkspace(wsName); IL.createWorkspace( wsName, "" );

} catch (Exception e2) { // Still couldn't create workspace, give up continue; } } // Checkout the object try { IL.openWindow( "CheckOut", "","" ); IL.setCheckoutMethod( true ); IL.setTargetWorkspace( wsName ); IL.checkout(); } catch (Exception e) { // Caught exception, some problem occurred System.out.println ( "Checkout failed, trying Required" ); try { IL.updateDependents( "Required", "latest", 18 ); IL.checkout(); } catch (Exception e2) { // Caught another exception, some other problem occurred, give up System.out.println( "Checkout still failed, giving up" ); continue; } }

IL.closeWindow(); // Hit ok in dialog box // Open workspace window IL.openWindow( "Workspace", wsName, null ); IL.setActiveWindow( "Workspace", wsName, null ); IL.openWindow( "RunProeTrail", "", "" ); boolean withGraphics = true; String trailFile = "trl_print.txt"; // Run trail file try { IL.executeProETrail( wsName, 0, withGraphics, trailFile ); } catch (ILScriptException x) { System.out.println( "Problem when running trail file: " + x.getMessage() ); } IL.cancel(

); // Intralink records this for some reason

Thread.currentThread().sleep(30*1000); // sleep for 30 seconds while (true) { try { IL.deleteWorkspace( wsName ); } catch (Exception e) { // Couldn't delete workspace, wait then try again Thread.sleep(10*1000); // sleep for 10 seconds continue; }

break; // workspace was deleted, exit loop } IL.closeWindow(); // Workspace window } br.close(); // Very helpful to close the file on Windows! } // end of run()

While more error checking would generally be necessary for production-quality code, this example illustrates the power of exception handling in building robust Pro/ INTRALINK scripting applications. Marc Mettes can be reached by email for questions relating to Pro/ INTRALINK Scripting, WebLink, JLink, Pro/TOOLKIT, or Pro/INTRALINK Oracle SQL. Click here for the author's email address

Wildfire 2.0 Makes BOM Balloons in a Jiffy By Florin Neamtu, Belcan Corporation

With the release of Wildfire 2.0, the BOM balloons for repeat regions have been greatly improved. These changes eliminate two of the biggest time sinks for designers and detailers—cleaning up BOM balloons for large assembly drawings, and having to split BOM balloons so they appear on all necessary components.

Drawing Clean-Up Detail Mode in Wildfire 2.0 provides new drawing file setup options to help you quickly and accurately position BOM balloons. Using the following options, it’s easy to control initial placement: def_bom_balloons_attachment EDGE def_bom_balloons_snap_lines NO def_bom_balloons_stagger NO def_bom_balloons_stagger_value 0.600000 def_bom_balloons_view_offset 0.800000 def_bom_balloons_edge_att_sym ARROWHEAD def_bom_balloons_surf_att_sym INTEGRAL

The No-Split Solution Wildfire 2.0 also makes it possible to directly show simple BOM balloons for multiple instances of the same component. For example, if a bolt is used 10 times in an assembly, a simple BOM balloon can be shown 10 times. (In previous releases, you’d have to use a Quantity balloon and then split it nine times.) Here’s how to do it.

1. After setting the BOM balloon region as QTY type (or Simple), select Table, BOM

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

Balloon, Create Balloon, Comp&View.

2. Use the Search Tool to find all instances of the component. In this example, we search for a standard bolt named “CSD*.”

3. The search yields six results.

4. After selecting all six bolts, click the OK button. 5. You are now prompted for the QTY number. In this case, it is “1” (i.e., 6 QTY balloons, 1 for each bolt).

Here’s an example of what you’ll see on screen.

Florin Neamtu is an engineer and PTC specialist/trainer in the Advanced Engineering & Technology Division of Belcan Corporation. Click here for the author's email address

Animate Flexible Components with Regemination By Toua Vang, Guidant Corporation While good for visualizing the motion of rigid components, the animation packages available today aren’t much help when it comes to elastic components. To get around this shortcoming, you can use “regemination”—my term for creating an animation by successive regenerations of a model file. Once your model is set up properly, it is just a matter of clicking a few buttons and typing a name to generate the JPEG files. Amazingly, it doesn’t take many JPEG files to create a nice-looking outcome. I’ve written a small Java application to give me more control over my animations, but any free animator off the web will also do the job.

Work/Life Balance: Making the Most of Regeneration Time ITT's Global Vault– Realizing the Value of PDS Pro/ENGINEER Wizards–DOS Batch Scripting on Steroids Exceptional Pro/ INTRALINK Scripting–And How to Avoid It

1. Create an extra-large surface feature. Pro/ENGINEER has a tendency to position the center-of-mass after a model has been regenerated. As a result, regenerating a model will move and/or zoom the model inside the Pro/E window—a problem for animating. To counter this, you can stabilize the display by creating an extra-large (on the order of 10x or so) surface feature, such as a box around the geometry. Be sure to turn off surface feature shading in the Model Display dialog box (Fig. 1).

Pro/ENGINEER Wildfire 2.0 MAkes BOM Balloons in a Jiffy Animate Flexible Components with Regemination

Figure 1. Model Display Dialog

2. Add a few simple Pro/PROGRAM statements, if desired. First, change the names of model dimensions that vary to logical terms. For example,

use DEPTH instead of d32. You can either edit each variable dimension for your animation manually or use Pro/PROGRAM to ask you to enter new values. Using Pro/PROGRAM is extremely easy: ■ ■

■ ■

■

To open up the Pro/PROGRAM editor, pick Edit Design under the Tools menu. In the INPUT/END INPUT section, insert a line after INPUT and type the dimension name and variable type. In the following example, WIDTH is the dimension name and it has a variable type of NUMBER (Fig. 2). Save and Exit. Answer Yes to “Do you want to incorporate your changes into the model?” and pick Enter to enter values. Pick the dimension you want to change, Done Sel, and enter the values. The model will regenerate. From this point on, Pro/ENGINEER will ask how you want to change the varying dimensions every time the model is regenerated.

Figure 2. Pro/PROGRAM Listing

3. Create JPEG files. To create the JPEG files, simply Regenerate, change the varying dimension values, and Save a copy as JPEG, choosing your page size and dpi. Without any scrubbing, 300dpi works well. Of course, this step is tedious so you may want to create one or more mapkeys to make things go more quickly. Anywhere from 10 to 20 images will create a decent animation. Remember to save all the JPEG files into a single folder and sequentially append a twodigit number to indicate the animation order. For example, for a part called “chassis. prt,” generate JPEG files labeled “chassis01.jpg,” “chassis02.jpg,” and so on.

4. Clean up the JPEG files as necessary. This is an optional step. I use a 600dpi setting and reduce the image size to create a smoother, less blocky image. This higher setting creates a 6600 by 5100 image, which Microsoft Photo Editor won’t even open. I could resize the image to around 640 by 480 using Microsoft Paint, but I instead resize all the JPEG files at once using a custom Java application. (A freeware program that works well is called JPEG Resizer, available www. virtualzone.de).

5. Animate the JPEG files. This is the fun step. You can use any JPEG file animator you can find free on the internet (for example, ImageToAVI, available at www.aswsoftware.com). I reduce the frames-persecond rate from 29 to 15 when using ImageToAVI since the animation would otherwise run too fast. My Java application allows me to start, stop, speed up, speed down, zoom in, zoom out, loop, repeat, and step forwards and backwards.

Figure 3. JPEG Animator Controls

Voila! Although this is a very crude way to create animations, it’s the only method I know to animate non-rigid Pro/ENGINEER parts. In fact, many of the steps are necessary just to work around some of Pro/ENGINEER’s quirks. The ability to animate non-rigid parts would be a nice addition to Pro/ENGINEER. Toua Vang is a mechanical designer at Guidant Corporation in Saint Paul, Minnesota. Click here for the author's email address