Is top-down design too cumbersome and time-consuming to use? Read some thoughts about TDD from Jason Clark in this issue.

Top-Down Design--A Method for Pro/ENGINEER Usersby Jason Clark, OceanWorks International

PTC/USER President's Messageby Evan Caille

Technical Committees Report Major Progressby Dan Glenn, Solar Turbines

Events Calendar @ ptcuser.org

Automating Pro/INTRALINK with UI Scripts

by Matt Meadows, Sequoia Etcetera

Opening Multiple Models Simultaneouslyby John Scranton, Undersea Sensor Systems, Inc.

Working with Decalsby John Randazzo, ASRC Aerospace, Kennedy Space Center

Creating a Straight Instance of a Bent Tubeby Dan Moran, Lang-MEKRA

ProfilesMagazine.com Home

Past Issues

Contact Us

Profiles Magazine is publishedquarterly by PTC/USER.

Copyright 2004 PTC/USER, Inc. All rights reserved.

Table of Contents

Page 1

A lot of people assume that top-down design (TDD) is too cumbersome and time-consuming to use. But these same people spend a lot of time tweaking models and blame the computer for faults. At the end of a design cycle, though, you can bet that systems built with top-down design will have required less time and end up being more robust.

The following tips build upon the information presented in my previous Pro/files article, “Reverse Engineering.” For those of you who didn't read that story, I’ve included a summary of Pro/ENGINEER's TDD toolset in addition to guidelines for planning and implementing a top-down approach.

Parametric Autonomy

Pro/ENGINEER is a parametric modeler at its core. The price you pay for this power, however, is that it creates parent/child relationships. With the toolset Pro/ENIGINEER provides, we can easily weave ourselves into a mess of circular references that overload our hardware as well as our own patience.

Parametric autonomy—perhaps the Holy Grail of top-down design—is a method to gain parametrics across far-reaching models from a single interface while at the same time minimizing parent/child relationships. Although it requires a little upfront planning, and sometimes duplicate work of creating geometry and relations, parametric autonomy offers some important advantages:

● huge reductions in time spent tweaking data in several models ● rapid alteration of models and design intent from a minimum of input

points ● documentation of design intent, and ● more efficient use of computer hardware.

Overview of Top-Down Design Tools

Here’s a quick summary of the TDD tools that Pro/ENGINEER currently offers.

External Reference Control. Available through the Utilities menu, this tool is really handy for protecting your models from inheriting references from unauthorized locations. Referencing from skeletons is best because the skeleton models are the foundation of your design and are controlled against change. You can also choose settings that allow only published geometry to be selected, and color or hide forbidden references.

Most favorable settings for External Reference Control.

If you’re using “mirror” to create parts or assemblies, you must change your scope setting from skeleton_model to all.

Global Reference Viewer. The global reference viewer (GRV), the granddaddy of the top-down design tools, tells you where your external references reside. If you've made copy geometry features, the GRV will let you see them.

Info: Parent/Child. Similar to the global reference viewer, this tool shows you any parent/child relationships. You can access Info:Parent/Child using either the right-click option on a feature or the Info top-menu.

Skeleton Models. Skeleton models provide the foundation for our parametric autonomy paradigm. The function of the skeleton model is to:

● contain key assembly constraints ● act as a conduit for “sketching” a design by adding geometry to

complement a layout ● serve as the hub of data sharing ● allow assembled components to interact with the parent assembly,

insulating it from failure of component placement.

Layouts. Layouts generate the key input data for skeletons, models, assemblies, and relations. Using a static 2D sketch along with parameter tables, we can communicate design intent and produce a history of a design’s evolution. A layout immediately reveals what the important datums are and what the design’s key dimensional constraints are. You typically use layouts from large assemblies down to a medium-size subassembly. Occasionally, interface layouts are used to control bolt circle information or connection information that may not be suitable to document on a subassembly layout. (More about layouts later.)

Data Sharing. Pro/ENGINEER’s copy geometry toolset is ultimately its Achilles heel. Sloppy use of copy geometry yields circular references and a terrible mess of parent/child relationships that produce a model that’s slow to regenerate. As a result, it’s better to use published geometry, which lets you “gather” references that can then be available for use outside the host model.

Using published geometry forces you to manage and control your copy geometry references. Think about a team environment. If a team leader is managing the assembly, it is his or her responsibility to control the references and the general

constraints of the assembly. By using published geometry, a team leader can therefore decide which references are valid and publish them for use, thus minimizing the problem of bad references. (Recall the External Reference Control option of “published geometry only.”)

Important! If you make copy geometry “independent,” do not use copy geometry. This rule is paramount. Once you make copy geometry independent, the management and tracing of errors becomes extremely time-consuming.

Packaging Components. Packaging is a great way to rough in component placement as you sort out your design. A good technique is to rough in your component placement (using packaged components), modify your skeleton, sketch in datum geometry (without referencing the components), and then redefine your packaged components to reference the skeleton.

Relations. Relations are the way to link the data input values from your layouts to your skeleton, part and assembly features. Using logic operations and condition statements, you can create geometry that can adapt under certain conditions.

ModelCHECK. While configuring ModelCHECK is outside the scope of this article, I do want to mention that this tool goes a long way toward helping to develop and maintain consistency in your model information. ModelCHECK will warn you about copy geometry references, external references, layer configurations and parameters. If you can set up a sound configuration of models, parameters, and such, ModelCHECK helps you maintain the consistency as well as future enhancements you want to incorporate (e.g., new parameters or renaming parameters).

Planning and Conceptualization

During the planning and conceptualization phase, we rough in our assembly and create our skeletons and layouts. Unfortunately, this is the stage that overwhelms most users new to TDD and the one skeptics complain takes too long. Once you have a procedure everyone follows and then practices, however, I don’t find that using TDD upfront adds much time to the finished design. In fact, planning is the most important step because we want to form—and document—our design intent. While all CAD systems lack good tools for this documentation process, Pro/ENGINEER makes up for this deficiency somewhat by integrating layouts and skeletons.

Home Coordinate System. Your “home” coordinate system is the one that’s common to all of the assemblies and subassemblies in your drawing tree. For example, if you were designing a car, you’d have assemblies for body, engine, and interior. These are major assemblies that relate to one another, so they would share a common coordinate system.

Layouts. Layouts let you sketch out your 2D representation. I prefer to use imported AutoCAD data or IGES data, but in a pinch you can do some rudimentary sketching in Pro/ENGINEER. In general, you should have one layout for every major assembly and possibly another one for each level below. Remember, the idea is to capture layout data that is specific to the assembly you’re working on.

Tips for Developing Layouts

● Place all interface datums in the layout using proper naming conventions.

Be aware that the yellow side of the datum gets created by the direction in which you pick your points when placing draft datums, so practice and get used to it. The datum direction is only important if you plan to use layouts for automatic placement. Identify your home coordinate system if applicable.

● Keep a table showing parameters pertaining only to the design and not to the layout itself (e.g., naming/part numbers for layout tracking). To facilitate this, I use a naming convention to filter out layout-related parameters, typically prefixed by “LY_”. Be sure to include a comment column to describe the parameters’ usage. You may want to create a standard table that you can retrieve, thus creating a standard look.

● FOCUS! I cannot overemphasize the importance of keeping your layouts focused. This is particularly vital because you can declare multiple layouts to assemblies and parts. For example, don’t put parameters for bolt circles on a layout that is for placing subsystems for the top-level assembly. To keep your layouts simple, you may have to make more than one.

● Avoid declaring layouts to each other. Otherwise, you can end up with a mess of parameters declared to parts that are not required.

● Use meaningful names for your key datums. The terms you use for your base datums will be the same as those for your parts, skeletons, and sometimes assemblies.

And remember: the layout is an excellent place to store design notes and document your design intent.

Start Parts and Layering. Before creating any geometry, it’s best to plan out what information will be required from the parts—typically in the form of parameters. If you already have start parts or templates, you’re probably all set but you might read through this section to be sure you’ve covered your bases.

Start parts are great simply because you can define a layering rule, default parameters, default relations, and so forth. Creating your defaults in your start parts also eliminates the need to do this with config.pro options, which never really worked well. When you create a start part, it’s a good idea to use a base start part with features common to all parts. I keep a start part for skeletons, piping parts, sheetmetal parts, and machined parts.

Tips for Using Start Parts

Default layer items are best served by associating entity items to be placed automatically on layers. You can set your layer properties either during creation by using the “new layer” button or by right-clicking the layer and selecting Layer Properties. When you name your layers, include a digit in the prefix so you can organize the layers in sequence.

The “isolate” function in the layer box is ideal for putting your assembly datums on a layer. Isolating a layer in effect tells Pro/ENGINEER to ignore the status of any items in the layer. This means that even if the items are on other blanked layers, Pro/ENGINEER will still show them.

Sample Layer Scheme

Setting the Layer Property

Modifying Layer Properties

Recommended Configuration Options

Below I have listed the recommended options for your config.pro and/or config.sup files. Use the config.sup to prevent user independent config.pro settings. (You will need to consult the PTC documentation because some config.pro options do not work properly when placed in the config.sup.)

RECOMMENDED CONFIGURATION OPTIONS

OPTION SETTING

allow_ref_scope_change yes

default_ext_ref_scope skeleton_model

default_object_scope_setting skeleton_model

enable_component_interfaces yes

force_new_file_options_dialog yes

maintain_limit_tol_nominal

yes

modelcheck_enabled yes

multiple_skeletons_allowed yes

new_parameter_ui yes

new_relation_ui yes

open_simplified_rep_by_default yes

sketcher_intent_manager yes

scope_invalid_refs prohibit

Default Datums. The default 3 planes and coordinate system usually requires an axis. Create any default datums you feel are necessary for most parts.

Parameters and Relations. Default parameters are used for consistency and compatibility with any formats you’ve defined. You can add parameters used for describing the part, bill of material information, and weight calculations. Pro/ENGINEER 2001 introduced a new parameter user interface as a hidden option, which you can use by setting the configuration option new_parameter_ui to yes.

Adding relations to your start parts is also quite handy. For example, you can create relations to store the mass of a part as a value or automatically add a prefix to your part number. In Pro/ENGINEER 2001, you can use the new relation user interface by setting the configuration option new_relation_ui to yes.

Settings to store last known value for weight and center of gravity.

Skeletons. Skeletons form the geometry prescribed by the layout. Since they are very lightweight and very fast to regenerate, I recommend having a skeleton for each assembly. If I’m working on an assembly that only has a few components, I’ll sometimes use assembly datums rather than a skeleton. But if your assembly has three or more components, skeletons are a better choice.

Multiple skeletons in an assembly are highly useful. When dealing with subassemblies that affect each other, I add the skeleton from one assembly to the other as a secondary skeleton. Remember that the first skeleton is placed automatically, so you want that skeleton to be native to your subassembly. When you add other skeletons, you can then place them.

Tips for Using Skeletons

● Name your interface datums. I find that using a prefix like “SK_” followed by the datum name used in the layout allows quick identification during query select.

● Use a layer scheme, typically defined by your start parts. Don’t be afraid to add more layers to group key datums. (By using the isolate layer option, you will see only the datums required for assembly.)

Component Interface. Component interfaces allow you to predefine your assembly datums in each part so that, at the time of assembly, there is no question about which datums to use. This option is particularly useful when it’s

time to pass designs off to others. Component interfaces are a hidden option in Pro/ENGINEER 2001, which you must turn on using the configuration option enable_component_interfaces and selecting yes.

Copy Geometry. Ideally, you should limit the use of copy geometry as much as possible. The nasty thing about copy geometry is the parent/child relationships that it can create. Imagine working in a large assembly consisting of a few hundred parts. If you make a copy geometry to a part in a subassembly, Pro/ENGINEER stores the reference required to regenerate the copy geometry in the part. To redefine the copy geometry, Pro/ENGINEER will now have to retrieve that assembly with those few hundred parts into session. The retrieval scenario applies in the Pro/INTRALINK environment as well, compounding the problem because Pro/INTRALINK will manage any changes to the large assembly across any versions saved.

I suggest using copy geometry for visual references only. Since we drive our key dimensional attributes from a layout, there is minimal need for copy geometry. In fact, minimizing copy geometry helps to fulfill parametric autonomy.

Feature/Datum Naming Conventions. As mentioned in the discussion of layouts, datum naming is key to documenting your design intent. Naming features can be just as important as naming datums. For example, rather than having “hole 123” show up in the model tree, naming it to “piston_bore” is much more helpful. I’m not suggesting you name everything, but simply that you name and document your design intent.

Implementing the Plan

Another place that users get overwhelmed in top-down design is at the “where-to-begin” dilemma. I find it best to start with the upper-level assembly and create its skeleton model and develop some geometry using datums. At the same time, I also create a temporary drawing of the skeleton to export as a .dxf. I then import the .dxf as groundwork to insert dimensions (parameters) in layout once the skeleton is well roughed in, or to sketch a 2D geometry reference in another CAD program. Note: Wildfire 2.0 has great AutoCAD support (from release 12 to 2000), offerng a host of options for importing your AutoCAD drawings cleanly.

1. Create the Skeleton Model

Sketching with curves is excellent because it provides

● easy references to use to define datum planes and axes

● robust geometric references for copy geometry, which you can then use to create part features (although I strongly caution against using copy geometry for part features), and

● a great way to control your datum and surface features in your skeletons.

When using a skeleton to “sketch” your idea, you will also be trying to get a reasonable start on usable dimension values. To define your design, you’ll find that you do a little bit of skeleton work and then layout work. You don’t necessarily do one before the other, and quite often the process is a parallel effort.

2. Associate Values from the Skeleton to the Layout

Once you have a working skeleton, it’s a good time to populate a layout that contains parameters required to drive the key areas of the skeleton. Declare the layout to your skeleton and start associating your values to your skeleton and parts.

Another complaint I hear about TDD is that it’s “too restrictive” and “I can’t edit dimensions on the fly, since I have to set values in my layout.” To disprove these claims, let’s assume you’ve created datums and curves, and perhaps even some surfaces in your skeleton. You’ve also made key parameters in your layout with no particular value since you don’t really know what’s required.

At this time, declare your layout (Declare option in the part menu). To link the values in your layout to your skeleton, you have to create relations. Don’t do this quite yet since you have different values in two places. You should therefore set the parameter values from your skeleton into your layout parameters. Now you may create your relations and regenerate your part. Of course, nothing will happen since the values are identical.

Making edits to many values using the layout can be tedious. At the same time, layout does not allow you to use the dynamic drag functionality to “eyeball” geometry changes. So what you do is simply “comment out” the relations in the relation editor to let Pro/ENGINEER temporarily assume these relations are not required. To comment out a relation, put a “/*” (slash-asterisk combination without quotes) on the leftmost side of the relation. Now start modifying your feature. When you find the dimensions you like, simply edit your layout with the values, uncomment the relations, and regenerate.

Creating copy geometry is a step in the process whether you use it to drive geometry (not preferred) or as general visual feedback geometry (preferred). At this point, we have a working skeleton and layout. You can now start creating some published geometry to contain the working references other designers (or yourself) are allowed to use for referencing your skeleton datums.

3. Populate Your Assembly

We’re in the homestretch now. By this time, you’ve put a lot of effort into creating skeletons and assembly structure by way of subassemblies and subassembly skeletons. You can now integrate parts you’re designing—whether they already exist or are being modeled for the first time—into your TDD assembly structure.

For existing parts, take the opportunity to update your models to utilize the layouts you’ve created. Since TDD can be implemented into existing designs (see my previous article, “Reverse Engineering”), you can slowly update your legacy models to take advantage of a TDD practice.

For parts you are now creating, you should assemble the part with its default datums so that they are the first features of the model and less likely to change. If you cannot use the default datums, be sure to make your assembly datums in the part as early as possible. As you design your part, keep in mind which features are going to be driven by the layout.

This is when you get the payoff from parametric autonomy. While copy geometry may be faster, you pay in the end for managing the references and for risking bad references. You will find you model the same “feature” more than once, but

once you link those features with the layout, any updates require only that the layout be in session.

4. Flex the Power

By this time, you’ve created an assembly, skeletons for the assemblies, and layouts to drive the skeletons and assembly components. Now you are most likely ready to start tweaking for a final design. You should start to experiment by modifying values from your skeleton models and layouts to test your model’s robustness.

Summary of Benefits

Since advocating against copy geometry for production design is likely to evoke a lot of complaints, I want to explain my reasoning and the benefits of my parametric autonomy approach.

1. Minimal parent/child relationships. The reason Pro/ENGINEER users (including experts) get into a lot of trouble is through the parent/child mess we can create. Whether designers are rushing or simply don’t know better, users often have to deal with something not regenerating because it cannot find its reference.

The solution? Minimize the dependencies. Rather than create a copy geometry in an assembly, create a layout to drive the geometry. You only have to deal with two dependencies—the layout and the part it is declared to. If you declare the layout to more parts, those declarations still have no effect on the first part unless you change the layout. In contrast, if you mistakenly create a copy geometry while in an assembly with 1,000 parts, you need that 1,000 part assembly in session to update any copy geometry.

2. Rapid changes with skeletons. If done well, you can create a simplified representation rule at the highest level of your assembly and include only skeletons of everything below it. With layouts and straight geometry modification, you can make large shifts in your model with minimal regeneration time. After saving your assembly and any modified skeleton models, you can then start regenerating the subassemblies to implement the change. In this way, you reduce the amount of hardware resources at any given time to ensure safe regeneration.

3. The “shown” dimension debate. When it comes to drawing documentation, the shown versus created dimension debate is a hot topic. Because you’re using dimensional values from a layout, you can in fact still show your dimensions. If you had used copy geometry features, you would have to create your dimensions from those features.

4. Robust feature creation. If you are just conceptualizing or in a proof-of-concept panic, copy geometry features can be very useful for a one-off design. If you design is for a “produced” item that others will work on or that will exist for a long period of time, however, parametric autonomy is a better investment. Your model will be stronger and adapt more readily to change.

Jason Clark is a senior designer and PTC applications administrator at OceanWorks International. He also chairs the Vancouver PTC/USER group. He can be reached by email at jclark@oceanworks.cc.

Table of Contents

Page 1

As one of the newer members of the PTC/USER Board of Directors, I have come to learn not only of the board’s dedication to provide a high-quality user conference, but also of its primary mission to serve as the independent voice of the PTC user community.

PTC/USER maintains a close relationship with PTC and supports a variety of venues for PTC to engage its customer base and assess customer satisfaction. One important way that we work to promote productive exchange with PTC is to meet regularly with senior management for open and candid discussions of the most pressing issues facing users. As an organization, PTC/USER also offers members a variety of forums—such as Technical Committees and Regional User Groups—to express a consensus of needs directly to PTC.

I would like to emphasize that PTC places great value on all of its interactions with both the PTC/USER board and membership. PTC carefully evaluates our feedback in its product planning process and in initiatives to improve its operating procedures in areas such as technical support and quality assurance.

In my new role as PTC/USER President, I am committed to carrying forward the legacy of outgoing board members who have so effectively represented the PTC user community in the past. I also join with the current board and staff to encourage all PTC customers to participate in PTC/USER-sponsored activities. Please visit our website (www.ptcuser.org) to discover the many opportunities and resources available to our membership.

Participate in PTC/USER—there is no better way to ensure your voice is heard.

Evan Caille is President of PTC/USER. He is employed at HP in Houston, TX and can be reached via e-mail at evan@ptcuser.org.

Table of Contents

Page 1

Over 100 committee members and 20 PTC product managers participated in the PTC/USER Technical Committee meetings in June. The facilities in Nashville were excellent and the PTC support showed tremendous commitment to the TC process.

The breakout story this year was the very rewarding attendance and feedback from our Windchill committees. While interest and participation have been building for some time, this year’s sessions were by far the most productive and well-attended. Special thanks to Windchill chairpersons Jeff Zemsky and Dominic Hand for their time and leadership, and to PTC for its management and development presence.

Leadership Changes

After serving as Director of Technical Committees, Evan Caille is now bringing his vast experience to the role of PTC/USER President. Congratulations to Evan and thanks for all of the hard work and great progress he has brought to the TC community. I know the information he passed along has been invaluable in helping me pick up the task.

In other committee leadership news, Howard Schimmoller has had to step down as the Core Modeling chair. Howard directed the committee through several initiatives, including a major white paper on model-centric design. Thank you, Howard, for your terrific service.

We welcome Ron Grabau back as he takes up the lead of Core Modeling. Ron has been active in the PTC/USER community for many years and has played several key roles, including a previous stint as Core Modeling TC chair.

Mark Crum has accepted full chairmanship of the Data Management Technical Committee. He has been doing an excellent job as acting chair since Ben Franklin’s departure.

Here are brief summaries of recent and planned activities prepared by several of the Technical Committee chairs.

Core Modeling. The Core Modeling TC had one of its best-attended meetings in June. While most of the subjects fall under nondisclosure agreements, the committee generally addressed updates to Wildfire 2.0 as well as future Pro/ENGINEER enhancements. The topics of discussion ranged from simple user enhancements to complex issues spanning multiple Technical Committees.

The Core Modeling TC is now looking at ways to organize better itself to address a wider range of topics. While still a work in progress, the reorganization should be finalized before the next conference. Although the Core Modeling committee is currently full, the group welcomes input from the entire user community. Contact any committee member to submit ideas and papers for consideration.

Customization. The Customization TC met with a number of new members. As interest in J-Link continues to grow, the committee plans to draft one of its new members to present on a J-Link topic for the January meeting. The committee is still open to new members.

The next release of Wildfire is at the end of the specification phase. PTC’s Scott Conover went over the planned enhancements. Customization committee members volunteered to review the specifications and offer feedback from the user point of view.

Data Exchange and Archiving. Members of the Data Exchange and Archiving Technical Committee reviewed improvements in Wildfire 2.0, enhancements to Wildfire 3.0, and white papers for future improvements. The TC will continue to meet via webcast every six weeks or so to comment on Wildfire 3.0 functionality before enhancements go into the software.

Drafting. Drafting conducted webcasts throughout the year. The June meeting was well-attended by member companies and PTC product management. Areas of discussion included implementation of Y14.41, user enhancements, symbols, future releases of PTC software, and white papers.

Manufacturing. Manufacturing met with 16 TC members and 4 PTC representatives. PTC’s Francois Lamy gave a presentation and demonstration of what’s new in Wildfire 2.0 for Manufacturing—the largest Manufacturing release ever. Francois then outlined the Funded Development Agreement PTC has with Toyota Motor Company, which has had a great impact on PTC's Manufacturing products. Some of the development done for Toyota will be exclusive for one year, but other enhancements will be available in Wildfire 3.0. In addition, Francois presented the projects planned for Wildfire 3.0.

Charles Farah of Sigmaxim's Smart Electrode also gave a presentation. The ability to automate the creation of electrodes has been kicking around the TC since 1997, and Charles demonstrated how far the development of this module has progressed.

With Manufacturing covering many modules—e.g., Production Milling, Turning, Mold Machining, Mold Design, and Wire EDM, the committee decided to create focused user groups to address specific topics. The Manufacturing TC will conduct a two-day workshop after the January 2005 meetings to test Wildfire 3.0 and provide some input to PTC before the final release, as well as address issues identified by the focused groups. The Manufacturing Technical Committee is open to new members

PDS. In June, the PDS Technical Committee announced the release of its Top Down Design and Change Management Process Guides. The TC is currently

working on the Release to Manufacturing Guide and will begin on the Collaboration Guide and Project Management Guide in the next couple of months.

Routed Systems. The Routed Systems TC meetings drew a number of long-time committee members who have put a lot of time and effort into the group. It was great to see a lot of the old familiar faces, including some who have been using the Routed Systems package for over 10 years. In the room was the best of the best, with one user mentioning another user, who in turn mentored another. It was like looking at a family tree of cabling knowledge.

PTC has made a lot of great enhancements and improvements to the tool. Wildfire 4.0 should have a whole new look and feel for cabling. It's exciting to see that PTC is paying more attention to electrical/mechanical design than it did 10 years ago and that the Routed Systems TC will have a lot of influence in what this tool becomes.

Sheetmetal. Because of either missed flights or timing conflicts, the Sheetmetal TC held two meetings on the Friday and Sunday nights prior to the international conference that covered the following topics:

● Wildfire 2.0. The discussions addressed mplementation planning within individual companies; testing procedures and findings; what was delivered compared with what was promised one-year prior; new functionality added to this release, and how it can be improved upon in future releases.

● Wildfire 3.0. PTC presented its plans for what the next release will involve, sparking several new discussions that will continue over the next few months and in our January meeting. Several new project specifications were divided among the TC members to review and provide feedback to PTC.

● Priorities review. TC members spent a lot of time reviewing previously established sheetmetal priorities and were able to remove several from the list because the requirements had been met. The TC is now reviewing Wildfire 2.0 to see if it can satisfy the other priorities on the list.

After one of the most successful and well-attended Product Update Briefings at the PTC/USER conference, the Sheetmetal TC is welcoming four new members. With these additions, the TC now boasts 17 members in North America that bring a range of experience and industry expertise to the table. The TC is still accepting members into our workgroup and has plenty of openings in the review group.

Going forward, the TC will focus on development of Wildfire 3.0 (and beyond) development to help enhance functionality and ease of use. Members will also continue to refine the TC’s list of priorities, which will then be combined with PTC’s. This will hopefully allow the Sheetmetal TC and PTC to develop a module that suits the user community as well as keeps PTC competitive in the marketplace.

The Sheetmetal TC would like to thank PTC, and especially Gilles Combette, for making the Wildfire 2.0 Sheetmetal module one of the most advanced and easy-to-use releases in some time. Thanks also to PTC management for their commitment to improving the Sheetmetal module with each release that follows Wildfire 2.0.

System Administration. The System Administration TC held its third meeting of

the year in June, including two face-to-face and two web-based sessions. It was a very productive meeting, with great participation from both PTC product managers and committee members. Discussions centered on support of the Wildfire 2.0 release. Topics included OS support, FlexLM support/reporting, license simplification, digital rights management, and installation changes. Pro/INTRALINK administration and administrator training were also covered.

Usability and Training. The Usability and Training Technical Committee discussed areas of usability, training and ModelCHECK. CADTRAIN is updating its COACH content to support Wildfire 2.0 and a free Wildfire 2.0 Primer is already available.

PTC provided an update on PTC University, which brings together all areas associated with learning—from searching for training opportunities to tracking enrollments to accessing role-based communities. Discussions continued about ModelCHECK’s expanded functionality and user interface enhancements in Wildfire 2.0. Software Factory also presented information on its geometry-based checking tools, PE-CHECK and PE-WALLCHECK.

Visualization. Visualization presentations and discussions focused primarily on enhancements to large assembly publishing. While this function can now be done only manually, it will be automated in Windchill Visualization Services for the upcoming release.

The committee was also briefed on the new 3D annotation capabilities (available in Wildfire 2.0 Object Adapter), upcoming JT import capability, and the Graphics Server roadmap. PTC gave an update on the roadmap for dvMockup/Reality and DSU 5, which now allows the application to run in the latest Unix O/S. Windows XP support will be addressed in DSU 6. Over the coming year, the committee will focus on enhanced collaboration capabilities, drawingless manufacturing, digital rights, and enhanced scalability.

Windchill Infrastructure. The Windchill Infrastructure TC reviewed the results of the work related to two primary areas—system performance and system management. On the topic of system performance, PTC presented the results of a survey conducted earlier this year to identify (1) appropriate database sizing information for future testing requirements and (2) performance bottlenecks experienced by various customers. One of the TC members then gave a presentation on his company’s customizations and requirements for system management.The committee selected three primary topics to focus on for the rest of the year: system performance, enterprise architecture, and customization. Webcasts will be held throughout this time to share lessons learned in each of these areas and provide feedback to PTC.

Windchill Solutions. The Windchill Solutions TC drew 31 attendees from North America, Europe and the Pacific Rim. The meeting started off with user presentations from John Deere, Pelco and Plug Power, followed by reviews and discussion of PTC's next-generation products. That presentation lead into four workgroup sessions focusing on PTC's new Business Process Guides. The breakout sessions covered:

● Enterprise Change Process ● Design Reviews ● Global Design Collaboration ● Search and Reuse

These topics, along with other related Business Process Guides, will receive additional attention over the coming year. A series of workgroups is covering

reporting and configuration management topics for the next two product releases.

The committee also held further discussion on the need for better collaboration with other TCs on topics where there is overlap, such as Visualization, Windchill Infrastructure, PDS, and Data Management. Several webcasts are planned over the next few months to continue work on the above topics.

Get Involved!

To find out more about PTC/USER’s Technical Committee activities or to sign up for a particular committee, please visit the PTC/USER website at members.ptcuser.org/Resource.phx/techcommittee/america.htx or contact me at dan@ptcuser.org.

Dan Glenn is Director of Technical Committees for PTC/USER. He is employed at Solar Turbines in San Diego, CA and can be reached via e-mail at dan@ptcuser.org.

Table of Contents

Page 1

Automation has always been a buzzword for Pro/ENGINEER customers and with good reason. Automated tasks are fast, efficient and always completed in the same manner every time. Although its worth cannot be directly measured, standardization contributes to improved quality as well as faster design and design changes. For companies, the bottom line is always time, quality and cost and automation at any level improves the bottom line.

Some of the earliest automations in Pro/ENGINEER involved mapkeys and trail files. Pro/INTRALINK 3.2 introduced a functionality called UI Scripting. Like Pro/ENGINEER trail files, UI Scripting was created to help debug Pro/INTRALINK. A user’s picks can be recorded and sent to PTC along with the customer’s database. PTC uses the UI Script file and database to reproduce the customer’s issue.

PTC also developed UI Scripting to behave like mapkeys. Users can play back recorded scripts just like mapkeys. These UI Scripts can even be added as dropdown menus to the Pro/INTRALINK user interface. The dual nature of UI Scripting makes it quite a bit more useful than Pro/ENGINEER trail files or mapkeys. All this functionality is supported by PTC Technical Support.

But there is one aspect of UI Scripting that makes it particularly powerful. UI Scripts are written in Java, which means they can be manually edited to take advantage of any Java function. While PTC Technical Support does not support editing of UI Scripts, a little thing like “unsupported” has seldom deterred Pro/ENGINEER users from taking full advantage of the available tools to automate products and processes.

Using UI Scripting in conjunction with Java functionality opens up a wide world of possibilities. The areas of interest include, but aren’t limited to, user, installation, and administrative tasks. Can you think of some Pro/INTRALINK processes you would want to automate?

If you’re worried because you don’t know Java, don’t be. For this foray into UI Scripting, the only prerequisite is a good working knowledge of Pro/INTRALINK.

Let’s walk through the process of recording and playing back a UI Script. We will use a script to open the COMMONSPACE and select the Root Folder. Finally, we will select every object in this folder. Your database won’t look like mine and production databases should never contain any objects in the Root Folder. Just choose a sub-folder that contains Pro/ENGINEER files.

1. After logging into Pro/INTRALINK, open the Scripting UI using [ctrl] + [s].

2. Switch to the Recording tab and enter a name for the Java script file to be recorded. Make sure that “Use Key Recording?” box is checked.

3. Click “Start” and record your picks within the Pro/INTRALINK UI.

4. Open a COMMONSPACE window and select your folder.

5. Now pick one object in the displayed list and use [ctrl] + [a] to select all displayed objects.

6. When finished, click “Stop”. When you record a script, it automatically

- saves the “.java” file to <.proi directory>\ .data\user.data\source directory

- compiles the script file and places the new .class file in <.proidirectory>\.data\user.data\lib (i.e.. it reads the .java file and makes a .class file).

- Switches to the Playback tab. Make sure “Use Watch Window?” is checked so you can watch each line execute for debugging purposes.

7. Click “Playback” and the Scripting UI will switch to the Watch tab. The commands are described in the table below.

Watch Window Buttons

Button Description

Step Executes one command.

Run Executes all commands.

Pause Temporarily stops a running script.

Abort Cancels a script even if it is paused or stepping.

The status icons are described in the table below.

Watch Window Status Icons

Button Description

= the current command

not executed yet

executed successfully

failed execution

currently executing

8. Step through the program. After selecting Step twice, my Watch tab looks like this:

We only made three selections, so why are there four lines? Sometimes Pro/INTRALINK executes more than one command when we click a button. By setting the folder, the software automatically filtered the display to show only the latest versions. PIV stands for product instance version. Every line displayed in the COMMONSPACE table is a PIV.

9. Continue to step through the program. If the script fails for any reason switch to the Errors tab. If no errors are reported, switch to the Messages tab for any additional information.

Pro/INTRALINK scripts can be run from the Scripting UI using the Playback button as we did above. But this method requires users to understand the scripting interface. Fortunately, PTC took into account the mapkey scenario for UI Scripting. UI Script creators can add a custom dropdown menu to the WORKSPACE or COMMMONSPACE folders by simply copying the compiled “.class” file to the “<.proi Load Point>\.data\user.data\custom\WS” or “<.proi Load Point>\.data\user.data\custom\CS” directories as shown below.

A Pro/INTRALINK client command line argument lets you record everything from user login to session close. Record a script from the command line by calling the Pro/INTRALINK client startup command, followed by the option “-r” and the name of the file to record.

proiclient.bat -- -r test.java

The script can in turn be executed from the command line using the Pro/INTRALINK client command line switch “-p”. The class to run must be in the “lib” folder. Command line scripts can even be run in nongraphical mode just like a Pro/ENGINEER trail file. The Pro/INTRALINK startup command shown below puts all these elements together. It calls Pro/INTRALINK in nongraphical mode and runs a UI Script.

proiclient.bat -- -nographics –p test.class

Although the above example isn’t very useful, there are numerous applications for UI Scripting. Incorporating the above functionality with a few manual edits can build very powerful automations. Have you thought of any applications for UI Scripting now?

UI Scripts can execute custom check-outs/ins, modify object attributes, and even produce custom reporting which helps focus on better-quality products. Administrative scripts can automate the purge process or export a Pro/INTRALINK BOM to an ERP/MRP system, reducing the time spent managing the data. Configuration scripts can be used to populate folders complete with permissions or to create users and groups in seconds.

Taking automation to the nth degree, UI scripting can be used in conjunction with a Pro/ENGINEER-driven configurator. It can automatically check out a configurable product and open that product in Pro/ENGINEER. After Pro/ENGINEER builds the product to a customer’s specifications and saves it to the

WORKSPACE, UI Scripting can modify the attributes and check the configured product back into Pro/INTRALINK—all without human interaction. Thus it can save valuable engineering time, increase quality by reducing user errors, and ultimately cut costs.

If you decide to delve deeper into UI Scripting, be sure to do all development and testing on a test server/client installation. Once completed and debugged, your scripts can be disseminated by copying them into each user’s .proi folder structure as described above.

Work through the entire process, practice your picks, and when you are ready, record your script. Always keep in mind the end goal. A script that saves time for every user every day may be just as valuable as the automation of a product line.

UI Scripting is a powerful tool available to everyone. Take advantage of it and make Pro/INTRALINK do the work for you.

Matt Meadows is a solutions architect at Sequoia Etcetera. He can be reached by email at mattm@sequoiaetc.com.

Table of Contents

Page 1

Have you ever wanted to open more than one model at a time from a workspace? In Pro/ENGINEER 2001 and Pro/INTRALINK 3.2, all you have to do is:

1. Select the files you want to open from the workspace using the left mouse button and the ”ctrl” key.

2. Click the right mouse button and select Open. Each model will open in its own window.

This works with family table instances or standalone models—with or without Pro/ENGINEER running.

A word of caution. Opening too many models at a time may cause video card problems or even lock up your system, depending on the system you have. I have successfully opened 11 at once, although things got a bit weird. Opening 10 or fewer at one time has not given me a problem.

John Scranton is a senior design engineer at Undersea Sensor Systems, Inc. (USSI) in Columbia City, Indiana, USA. He can be reached by email at jmscra@undersea-sensors.com.

Table of Contents

Page 1

Decals are a great way to add a company logo or label and just a bit more realism to a photorendered model. But do you know the shortcuts for making decals easier to use and providing better display quality?

The first two tips below outline the basics of creating and applying decals. The second two are timesavers that will improve the flexibility and quality of the rendered output. Note: Although you don’t need Pro/PHOTORENDER to create decals, the final product will be better if you create your images with it.

Creating a Decal

1. Open model on which decal is to be applied.

2. Click on View, Color and Appearance.

3. Add a new “color” by clicking on the + symbol in the right-hand side of the Appearance Editor window. Name the new color if desired.

4. Click on the Map tab in the Appearance Editor window.

5. Click on the empty gray square located under the Decal heading.

6. Click on File, Open or click the + in the Appearance Placement window.

7. Select an appropriate graphics file to use as a decal and click Open.

8. Click on the desired decal file in the Appearance Placement window and click Close. You now have a decal ready for application.

Applying and Adjusting a Decal

1. Click on View, Color and Appearance.

2. Select the “color” that represents the decal from the Appearance Editor window.

3. Select where the decal will be placed from the Assignment heading of the Appearance Editor window (i.e., Part, surface, quilt), and select the

corresponding reference.

4. For best results, orient the model so that your view is normal to the surface where the decal will appear.

5. Click on the Apply button. Note: If applying on a created surface, choose “both” when prompted for the side on which to apply the decal.

6. To edit the size, quantity and location of the decal, click on the picture of the decal preview located under the Decal heading of the Map tab of the Appearance Editor window.

7. Click on Mapping to adjust to the shape of the geometry where the decal is to be applied.

8. Click under the options of Copies to adjust the number of occurrences of the decal. Scale will turn into Copies, and the amount can be adjusted there.

9. Drag the X and Y dials of Scale to size the decal.

10. Drag the X, Y and Rotate dials of Position to adjust the location of the decal.

11. Click Close on both the Appearance Placement and Appearance Editor windows when you are done making adjustments.

The first timesaving tip involves creating an “outline” of where your decal will appear. This step has several benefits—it takes the numerical guesswork out of scaling the decal, makes it easier to adjust its proper location, and automatically “crops” the decal when you scale it, so that you cannot exceed the size outline of the created surface.

Creating the Outline for your Decal

1. Click on Sketched Datum Curve button of the Datum toolbar.

2. Sketch an outline to represent the size and shape of the finished decal.

3. Complete the feature.

4. Select Edit, Fill from the pulldown menus.

5. Complete the feature.

6. Apply and adjust the decal as instructed above, using the created surface bounded by the sketched curve as the assignment for the decal.

7. To adjust the location of the decal on the model, you can edit the surface feature. This allows access to the dimensions used to create it, and thus provides an easy (not to mention parametric) adjustment to the decal location. Because of the novel way Wildfire operates, if you adjust the curve location, the corresponding surface will not adjust.

8. Render the model if desired.

As you will see when you implement these steps, the created curve does not render with the model. The one caveat to this method is that the appearance of the decal on the rendered output is poor quality.

This is where the second tip comes in. What you can do now is offset the surface that was created for the decal by a minute amount. This will eliminate the “slicing” effect on the decal and the small offset will not be noticeable in the rendered images.

Creating the Offset for your Decal

1. After completing the preceding tip, select the surface that represents the decal outline.

2. Select Edit, Offset from the pulldown menus.

3. Enter an offset amount for the surface (.001” recommended as the minimum amount).

4. Complete the feature.

5. Apply and adjust the decal as instructed above, using the offset surface as the assignment for the decal.

6. Render the model if desired.

John Randazzo is a mechanical design engineer at ASRC Aerospace, Kennedy Space Center. He can be reached by email at John.Randazzo-1@ksc.nasa.gov.

Table of Contents

Page 1

If you’re designing an exhaust pipe or other formed tube product, you generally must create your Pro/ENGINEER model in its final state, ready for assembly. Wouldn’t it be nice though if you could easily generate the original straight tube stock from the bent model?

This tip uses family tables, relations and user-defined parameters to create a straight tube instance from a formed tube. Because a tube stretches as it is bent, the relation equations use a stretch factor for determining the actual length needed. Using the steps outlined in this tip, holes in the tube also can be correctly positioned on the straight tube based upon their intended locations on the bent tube.

The generic model for this application is created from straight datum curves set at specific angles to each other. For each bend that is not coplanar with the previous bend, you must create a pair of datum planes, one normal to the existing straight curve and the other for sketching the new curve. A pipe feature with a constant radius is created through the endpoints of the datum curves to form the bent tube. Holes can be placed anywhere along the tube as long as their references stay relevant as the tube becomes straight. Holes between bends are dimensioned from one of the ends of the datum curve defining that portion of the tube.

User-defined parameters are created to represent the segment lengths, the internal bend angles, and the hole placement dimensions. A Yes/No parameter (BENT) is set in the family table and is used through a conditional statement in the relations table to control the lengths and angles for the bent and straight instances. Its value either sets the dimensions to their bent values for the bent instance or makes length adjustments and sets the internal bend angles to 180 degrees for the straight instance.

In order to make this all work properly, we have to make a couple of assumptions:

1. The bend radius remains the same throughout the formed tube. It is possible to use different radii but my application uses a common radius for each tube. Different bend radii would require multiple RAD parameters and likely different bend stretch factors (BSF parameters) because tube stretch can vary with the size of the bend radius.

2. Tube stretch is a linear function of bend angle.

Determining the Stretch Factor

The stretch factor is determined empirically. Straight tubes are measured prior to bending and measured again with CMM equipment after forming. The

difference between the centerline length of the bent tube and the length of the straight pre-bent tube is the amount the tube stretched. Divide that amount by the sum of the bend angles to get the bend stretch factor in millimeters per degree.

It can be useful to blank the pipe’s centerline by putting the pipe feature on a layer and blanking that layer. The solid will continue to display but the centerline will disappear.

Explanation of the Length Adjustment for Stretch Formula in the Relations File

In the following diagram, you will see how we arrive at the length adjustment for the stretch formula.

(Click diagram to enlarge)

Relations File

I have included the relations file that I use to create my bent and straight tube instances. You can copy this file and then edit the appropriate values for your application.

/* START OF RELATIONS FILE

/* The dimensions must be renamed prior to installing this relations file

/* - bend angle dimensions should be named D_BENDn

/* and linear dimensions should be named D_SEGn and D_CUTn

/* where n represents a number.

/* ANGn defined to simplify adjustment calculations:

/* Delete unused ANG’s or add additional ANG's as needed.

ANG1=(180-BEND1)/2

ANG2=(180-BEND2)/2

ANG3=(180-BEND3)/2

ANG4=(180-BEND4)/2

ANG5=(180-BEND5)/2

/* Adjustments to lengths per bend:

/* Delete unused BD's or add additional BD's as needed.

BD1=ANG1*RAD*PI/180-RAD*TAN(ANG1)-BSF*ANG1

BD2=ANG2*RAD*PI/180-RAD*TAN(ANG2)-BSF*ANG2

BD3=ANG3*RAD*PI/180-RAD*TAN(ANG3)-BSF*ANG3

BD4=ANG4*RAD*PI/180-RAD*TAN(ANG4)-BSF*ANG4

BD5=ANG5*RAD*PI/180-RAD*TAN(ANG5)-BSF*ANG5

/*************************************************/

/* Delete unused D_SEG, D_CUT and D_BEND lines. */

/*************************************************/

IF BENT == YES

/* Segment lengths:

D_SEG1=SEG1

D_SEG2=SEG2

D_SEG3=SEG3

D_SEG4=SEG4

D_SEG5=SEG5

D_SEG6=SEG6

/* Cut dimensions to TSC:

D_CUT1=CUT1

D_CUT2=CUT2

D_CUT3=CUT3

D_CUT4=CUT4

/* Bend angles:

D_BEND1=BEND1

D_BEND2=BEND2

D_BEND3=BEND3

D_BEND4=BEND4

D_BEND5=BEND5

ELSE

/* Segment lengths adjusted for stretch:

D_SEG1=SEG1+BD1

D_SEG2=SEG2+BD1+BD2

D_SEG3=SEG3+BD2+BD3

D_SEG4=SEG4+BD3+BD4

D_SEG5=SEG5+BD4+BD5

/* Last segment should reference only one bend.

D_SEG6=SEG6+BD5

/* Cut dimensions to TSC:

/* Check for reference to the appropriate bend

/* and replace 'n' with correct bend number.

D_CUT1=CUT1+BDn

D_CUT2=CUT2+BDn

D_CUT3=CUT3+BDn

D_CUT4=CUT4+BDn

/* Bend angles:

D_BEND1=180

D_BEND2=180

D_BEND3=180

D_BEND4=180

D_BEND5=180

ENDIF

/* END OF RELATIONS FILE

Steps to Create Bent and Straight Instances

1. Create the following parameters: BENT (Yes/No), RAD (common bend radius), BSF (bend stretch factor), CUT1 through CUTn (cut dimensions), SEG1 through SEGn (straight segment lengths), and BEND1 through BENDn (inside bend angles). These parameters can also be preset in a tube “startpart”. Enter the values for the tube being designed.

2. Create a bent tube model using datum curves with bend dimensions referencing inside angles and straight segment lengths between ends and Theoretical Sharp Corners (TSCs). The Pipe feature will be created through the endpoints of the curves. Holes between bends should be dimensioned to one of the TSCs. Use the RAD parameter when defining the Pipe feature’s bend radius.

a. In this example, the first two straight segments are sketched on the FRONT datum plane (see figure 1).

Figure 1.

b. The second bend is not coplanar with the first bend so the third straight segment must be sketched on a datum plane (DTM1 in this example) set at an angle to the previous sketch plane (see figure 2).

Figure 2.

c. For sketching references, select the previous curve and its endpoint (see figure 3). Dimension it with the appropriate length and angle. See figure 4 for the completed three curve segments.

Figure 3.

Figure 4.

d. Create a Pipe feature with constant radii through the endpoints of the curves (see figure 5). When prompted for the bend radius, type RAD.

Figure 5.

e. IF there are cuts in the tube, create them now, dimensioning them to segment endpoints.

3. Rename the varying dims (Modify|DimCosmetics|Symbol): D_SEG1 through D_SEGn for the segment lengths, D_CUT1 through D_CUTn for the cut dimensions, and D_BEND1 through D_BENDn for the internal bend angles. The pipe feature has been suppressed for clarity (see figure 6).

Figure 6.

4. Test the tube construction by changing the internal bend angles to 180° to ensure it forms a straight tube and the cuts don’t fail.

5. Open an Edit Relations window and paste the contents of Tube_Bending_Relations_File.txt

6. Edit the relations:

a. Delete unused (or add more) ANGn, BDn, CUTn, SEGn, and BENDn statements.

b. Check that the bend angle reference in the cut dimension adjustment statements refers to the correct bend (ex: D_CUT1=CUT1+BD1).

c. Edit the last SEG statement in the ELSE section to include only one BDn variable.

7. Close the editor and check the text message area for an indication of an error. Re-edit the file if necessary. Pro/E will add a comment line explaining the error found in the file.

8. Create a Family Table with two instances: PARTNO_BENT & PARTNO_STRAIGHT (see figure 7).

Figure 7.

a. Add the BENT parameter and set its value to NO for the straight instance and to YES for the bent instance. It should be set to YES in the generic.

b. Add any other parameters unique to either the bent or straight instances.

c. Verify the instances by selecting the Verify icon and clicking on the VERIFY button.

Now you're all done!

Dan Moran is a designer at Lang-MEKRA in Ridgeway, SC and he can be reached via email at dmoran_mechengr@yahoo.com.