Is top-down design too

cumbersome and time-

consuming to use? Read some
thoughts about TDD from
Jason Clark in this issue.

Automating Pro/INTRALINK with UI

Top-Down Design--A Method for Pro/ENGINEER
Scripts
Users
by Jason Clark, OceanWorks International by Matt Meadows, Sequoia Etcetera

Opening Multiple Models

Simultaneously
PTC/USER President's Message by John Scranton, Undersea Sensor
by Evan Caille Systems, Inc.

Technical Committees Report Major Progress Working with Decals

by Dan Glenn, Solar Turbines by John Randazzo, ASRC Aerospace,
Kennedy Space Center

Events Calendar @ ptcuser.org Creating a Straight Instance of a Bent

Tube
by Dan Moran, Lang-MEKRA

ProfilesMagazine.com Home

Past Issues

Contact Us

Profiles Magazine is published

quarterly 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.
 Setting the Layer Property

Sample Layer Scheme

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.