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