2001 PTC/USER International User Conference
Daily Email Newsletter 3
Wednesday, June 20
brought to you by PTC/USER
written by Peter Nurkse
Today's topics:
The forest fire was still burning today, as close as 5 miles to the nearest
homes in Reno. Less smoke than before, but still 3100 firefighters, 260
fire engines, 60 bulldozers clearing firebreaks, 30 tank trucks just hauling
water, 12 air tanker planes dropping thousands of gallons of fire retardant
each at a time, and 16 helicopters dumping water on the difficult places
to reach. Great watching for helicopter enthusiasts, on the way home I
saw a twin rotor Vertol, and a single rotor huge Sikorsky Sky Crane, just
working on one hillside.
Strangest sight of the conference perhaps was looking up to the sky
at noon, and seeing the sun hanging there as a simple orange disk, just
like a spectacular sunset---but in the middle of the day.
Less Beef?
There is less substance about Pro/E and PTC in this year's newsletters,
partly because the user group removed one standard item on the agenda,
in response to evaluations of last year's conference. That was the Management
Panel, when PTC managers in a range of different areas would respond to
questions written and submitted in advance.
I know the Management Panel session was rich in Pro/E and PTC information,
because I had to scramble each year to try and record what was said. This
year the gap was filled by a "featured speaker". There were three featured
speakers this year, talking about racing for the world water speed record,
and trends in industrial design, and building an electric car. They were
all dynamic and interesting speakers, but they just didn't have much detail
about Pro/E or PTC.
Anyone who has ever tried to organize a user group probably knows the
problem: how do you develop the technical content of user group sessions?
I think of a Chinese saying:
"Those who speak don't know, and those who know don't speak"
True, very often the users with the most knowledge of Pro/E or other
PTC applications are the last people who will agree to speak in front of
hundreds or a thousand other users. While the people with less knowledge
(like me, I'll admit) are often more ready to talk. At our last local Silicon
Valley user group meeting, we started with 12 vendors (all ready to talk)
and 2 users in the audience, although the ratio did improve as the meeting
proceeded.
So if you have ideas or suggestions how to develop the technical content
of the meetings, send them in to Pro/USER. This might be a good time, right
after this conference.
Design Meets Manufacturing
Robert Kamrath of Gill Industries gave this talk on his experience
with Pro/Process for documenting assembly sequences. You think the title
might be a bit ambitious, 'Design Meets Manufacturing'? Robert pretty much
agreed, he said he's the only designer using it there, and none of the
manufacturing process engineers are using it.
Which does point out that Pro/Process isn't just yet another module,
it's really an ambitious attempt to provide a tool to help document manufacturing
processes, an area in which PTC is becoming more interested. But as an
extension of a 3D design tool, it might be limited in success. Manufacturing
process engineers seem to be heavily 2D in their orientation, unlike NC
programmers and other mfg. engineers who more ready to use 3D tools.
A large number of people probably use Pro/Process just to create sequences
of exploded views, just because it's the easiest way to do that. And a
good number of people might use it just even to create explode lines in
a single exploded view, because explode lines are more difficult any other
way.
But Robert showed how Pro/Process can be used to really document steps
in a process (as the name Pro/Process suggests). The model tree of a complete
Pro/Process assembly is a series of steps, Step 1, Step 2, and so on. Among
the steps in his example, Robert had not just assembly, but also welding,
forming, disassembling, coating, even lubricating. Every one of these is
a documented step, even though several of them involve no visible change
in the geometry. Each step could be the subject of a drawing, but that's
optional. For Robert, the goal was to document the process, and that didn't
require drawings at every step.
The Pro/Process assemblies are .asm files, easily confused with a normal
design assembly .asm file. So Robert suggested including a final "p" in
the name of the Pro/Process assembly. And he used a technique which many
people have used in design, when sharing an assembly among different users:
he created the Pro/Process assembly, and then assembled in it as the first
component the design assembly.
When sharing an assembly among different users, this technique lets
everyone get their own individual top-level assembly, to control personal
preferences, and still everyone is sharing the same assembly, the first
component in each of their individual assemblies. For Robert the benefit
was an independent Pro/Process assembly file, independent of the design
assembly, but still completely associative with the design assembly.
Some other points:
-
Pro/Process is just showing visual outlines of components, and doesn't
calculate all over again their position in the assembly (it gets that information
from the design assembly). So components can be suppressed anytime, without
Pro/Process even caring, it just puts a bracket around the name of that
component.
-
when you bring in a component, it's immediately visible. But if you disassemble
a component, it will still remain visible until you exit that step.
-
if you reassemble, after disassembling, you do have to reference that step.
You can't just grab the component and reassemble it again.
Data Transfer Notes
As usual, Asa Trainer, the Data Exchange manager at PTC, had a lot
of detailed information on developments. The company emphasis now on openness
and collaboration probably can only benefit data exchange.
Asa said there are plans to create a new Data Exchange and Archiving
Technical Committee, where users and PTC can work together on issues. Anyone
interested in particpating should contact Asa at atrainer@ptc.com.
Here are some of the details Asa mentioned:
-
2000i2 reads and writes CATIA V4 models (not drawings)
-
Pro/Med is a new package for exchanges with Medusa
-
pretty big news with 3D DXF: 2001 will support reading and writing 3D DXF
wireframe, and 2002 will add DXF faceted surfaces
-
2001 imports and exports ACIS (.sat) files
-
2000i2 and 2001 import tessellated formats like STL and VRML. You can create
datum features on top of the tessellated geometry.
-
2002 will import/export Pro/Desktop assemblies into Pro/E direct
-
2002 will import/export Parasolid files (foundation of a good many other
solid modeling systems)
-
2002 will add STEP 209, for geometric and material properties, including
3D notes
-
2003 will do 2D CATIA II exchanges
-
2002 and 2003 will introduce data exchange with Pegasus, a Medusa follow
on
-
2002 will import (only) SDRC file. This project was just advanced by a
couple of revs. with the news of EDS buying SDRC.
-
2003 may introduce CATIA V4 drawings
-
2003/2004 may include CATIA V5 exchanges
-
CGM 2.0/3.0 partially supported on 2002 (a rev. update for CGM)
-
VRML 2.0/3.0 supported on 2002, with assemblies and color later.
-
support for STEP associative drafting began on 2000i
-
Pro/E will not import higher degree surfaces (higher than 3rd degree) even
though Pro/E does not create those surfaces interactively
-
the ATB is first used for CATIA transfers on 2000i2, and will be developed
further
-
a considerable development on 2001 is that you can edit and manipulate
the profiles contained within imported geometry, and use them to create
more useful Pro/E geometry.
-
and an ambitious project for 2003 is a semi-manual process to convert 2D
profiles to 3D geometry. Asa has heard of the claims for fully automating
that process, but he doesn't believe them. Some human intelligence seems
still needed.
-
use of STEP validation profiles was launched on 200i2. That compares volume/surface
area/mass of parts on original system, and same parts on Pro/E, to check
for accuracy.
-
e/Engineer (remote Pro/E sessions) can be used for batch data exchange
processing, both import and export, on 2002.
-
the automatic Imported Data Doctor is getting continued development. It
will for example fix missing and overlapping surfaces, also edge and vertex
problems. You can choose to freeze certain surfaces before running the
Doctor, so that they won't be changed at all. You can split surfaces, which
often makes them easier to repair. And you can collapse your own geometry
into the imported geometry: for example, build a missing surface in Pro/E,
then collapse it into the imported feature.
-
ATB will be used for UG exchanges on 2003/2004 (using ATB for SDRC is getting
priority).
Asa suggested evaluating any data exchange needs by end use:
-
if end use is visual image or space allocation, even a solid model may
not be needed, tessellated model for example may be appropriate
-
if end use is design interface, real geometry becomes needed
-
if end use is manufacturing or analysis, then the cleanest geometry possible
is needed.
Constructing
Robust Models
Daryl Reece had a very stimulating presentation on constructing robust
models. You'd need to see the visuals to get all his points, probably if
you email Daryl at Caryl.Reece@arris-i.com he can get you copies.
We look at part structure really in 1-D, the model tree. That is truly
a 1-D image of a 3-D model. No wonder we have some problems understanding
models.
Daryl worked with scripts to generate some 2-D images of parts. That's
more than a model tree. In a 2-D image the features spring up and outward
from the root, like the trunk and branches of a tree. And there are lines
between them, to indicate the dependencies.
There's apparently an entire branch of computer science that deals with
this kind of graph, 'graph theory'. From this point of view, Daryl said
that "Pro/E is a database with a pretty graphics front end". It's the interconnections
between the features that defines the part. And laying them out in a 2-D
graph you can see those interconnections much better than in a 1-D list,
like the model tree.
Looking at different graphs of different parts, and their visual appearance,
Daryl came up with these 3 categories of parts:
-
Tangled Vine. Knotted messes, often faster to construct than any other
kind of part. Minimum or no planning. Long single branches along side other
long single branches. Product of disjointed thought processes, just chosing
what's convenient for a relationship. Difficult to maintain. Impossible
to reuse.
-
Bushy Shrub. Stable simple models, most features tied back to a very few
base features (a fairly conservative and safe way to model parts). Very
shallow structure. Minimal forethought needed, just always go back to a
base feature. Stable with change, but changes are time consuming.
-
Deep Tree. Robust sophisticated models. Well defined branches. Links flow
based on design intent. Thought required (imagine that) with each feature
creation, what does it relate to. Highly reusable. Highly stable.
Daryl mentioned that of these 3 categories, the Tangled Vine type
of part is often 10% to 20% faster to create (mainly because, no don't
have to think very much). But as soon as changes or reuse happen, then
much more time may be spent trying to figure out the structure and trying
to incorporate changes in it.
Some tools for maintaining your part tree, pruning your part tree, keeping
it robust and healthy:
-
name features constantly, you probably won't remember them even in 6 months
-
reorder features regularly, to group them into branches
-
reroute entire branches, shaping the tree
-
use Info and the Global Ref. Viewer for parent/child relations
-
for symmetric parts, make all the parent features on one side, don't jump
back and forth between sides
-
use the most stable entity for references (usually surfaces will be more
stable than edges).
Would be good to see some more people approach this subject, expanding
our view of relationships in a part from 1-D (Model Tree) to 2-D (a graph).
Looking at a relational database in 3-D is a big current task in computer
science, that might be asking for too much. But a 2-D view of our relational
databases, our parts, should be possible.
Local Color in Reno
Pro/USER has paid my conference fees, but I've paid my travel for this
conference. Worth it, just drove up, but Tues. I went hunting for a really
cheap place for my last night in Reno. And on travel I've often found that
really cheap places have a lot more local color than the big business convention
hotels.
Driving down Virginia St., one of the main streets in Reno, I found
the Ranch Motel. It's in the classic U shape, about 20 units arranged like
that around an open parking lot in the middle.
From the street I could see this place had potential, the parking lot
had cracks running all over it with grass growing. And under one very dusty
car, which had sort of settled down on its tires, there were even weeds
growing.
As I drove in, I couldn't help seeing a stack of rolls of old carpet
piled up beside the first unit, obviously been there a while. There were
a couple of mattresses piled up on end against the wall of the second unit.
They were held in place by a completely broken down couch sitting out on
the asphalt, which looked as if it'd fall apart if you tried to move it.
To complete this scene, there was a full size refrigerator sitting in the
parking lot too, facing the building---so you saw the back of the fridge,
the condenser and coils. Sort of as if someone planned someday to work
on this refrigerator.
I drove down to the office, admiring a bird feeder hanging from a chimney.
A hand lettered and hand colored sign told me to ring the bell. I did,
and the door opened into a combination office and living room. And the
motel keepers were a perfectly nice couple, very friendly, and very obliging.
They did take cash only, I saw that sign. And there was another sign I
haven't seen before in a motel:
"No Working on Cars in the Parking Lot"
Perhaps that's why the car with the weeds under it is still sitting
there, nobody can work on it.
My room was $25 a night, couldn't beat that. Walking there I saw an
abandoned shopping cart a couple of doors down. The room next to mine had
a large black cat in the window, looking at me, plus some potted flowers
out in front to add the homey look (some of the guests were long term,
paying by the week).
Inside my room was perfectly clean, even if the couch was about as broken
down as the couch sitting in the parking lot. Lots of room, including a
kitchen area with a double burner stovetop, and a full size refrigerator
(working fine).
When I checked in, the manager told me there was no hot water in the
sink in the room. So I was a little surprised when I tried it, and found
both hot and cold water. Went into the bathroom, tried that sink, and found
only cold water. Then tried the shower, and found no water there at all,
hot or cold. So I washed up in the room sink, the one with both hot and
cold. Probably more ecological than any shower, I didn't use much water.
Outside the main entrance of the Reno Hilton conference hotel was a
monumental life size bronze sculpture of 7 wild horses galloping. And inside
the entrance another monumental bronze sculpture of a Pony Express rider
picking up the mail.
But if a real working cowbody in his gear had shown up at the Reno Hilton
to get a room, he might have been told to go away. However at the Ranch
Hotel he'd probably have been right at home, the Ranch Hotel looks just
like a lot of working ranches. Plus he probably could have kept his horse
there too, tied up to that refrigerator in the parking lot, perhaps.
Peter Nurkse
Sun Microsystems
peter.nurkse at sun.com
|