2002 PTC/USER Atlanta Conference

Daily Email Newsletter 3

Wednesday, June 12
brought to you by PTC/USER and PTC
with Sun Microsystems
written by Peter Nurkse

Today's topics:
 


This could be the first Wednesday issue of this newsletter which actually appears on the last day of the conference. Just thanks to a laptop on the flight home, it did make the time fly. As usual, I end up glad I made the effort to do a newsletter, even just for myself. Certainly it made me pay closer attention in the sessions.

Next year the conference will be in Orlando. Hope this year's newsletter again gives an idea of what you can pick up and learn at a conference, much more than I can record.
 

Control Challenge


In the Top Down Design session, Howard DeRuyter of PTC mentioned incidentally that a big company down in L.A. removes all external references, and redefines all parts as standalone parts, before they are released.

And if you think that's strange, consider Cisco Systems, a leading light of the global Internet. Cisco converts their Pro/E files to 3D IGES wireframe files, and stores only the IGES files in their corporate database.

Both these companies, and I'm sure many others, seem to be struggling with control of Pro/E files. Those parametric relationships that delight the Pro/E user may also be the despair of corporate database people, who can't tolerate the slightest ambiguity.

I relate this situation to the "Three Essentials" that Dick Harrison and Jim Heppelman emphasized on Monday: Create and Collaborate and Control. Now parametric relationships work well for Create. And although parametric relationships are more difficult for Collaborate, well, we can just strip out the parametric relationships by converting Pro/E files to visual files (like ProductView), and distribute those visual files to people outside the design groups.

But the biggest problem for parametric relationships seems to be Control. That has to be why the big company jumps through hoops at release. trying to avoid parametric relationships between parts in the released data. As a company based on parametric technology, PTC probably has some amount to learn about the Control issues---listening to companies with Control issues, understanding them, and even sympathizing with them. Because only sympathy will probably make a good foundation for working on Control, customers need vendors who sympathize with their problems.

And although the classic Control problems are released files, with the growth of outsourcing Control issues can popup before release, in the design process. 3 or 4 or 5 different companies can each be contributing to a design, dividing up and recombining the design work in different ways, and passing Control back and forth like a football. As usual, perhaps, we've got ahead of ourselves in technical progress, and a lot of the appropriate Control infrastructure for distributed extended enterprise product design probably is lagging behind or doesn't even exist yet.
 

Intralink Tips and Tricks

 
  • map folders to projects or other business criteria. Then name a storage cluster for each folder, and a vault for each storage cluster. Then you'll end up with equal numbers of folders, storage cluster, and vaults---each group named alike. Main reason here is that Oracle reports are keyed on vaults. And if you want to know how much disk space a project is using, that project has to have a vault of its own. Also, by just aligning folders and clusters and vaults this way, you make life simpler for everyone. A folder has a cluster has a vault, all named the same, end of story.

    •  
  • along the same lines, to really know how much data a project owns, you need to put replicated data from other sources in a replicate vault of its own.
  • set size limits for vaults, so that backups will run in a reasonable time. When a vault fills up, make it read only, and start a new vault. You can name each inital vault like this: Project1. When it fills, start a new vault, Project2. This way you're never at a loss to name the next vault in a series of vaults, and the succession is clear to everybody.

    •  
  • whenever you restore a backup, restore the newest vautlts first, then the older ones. People are more likely to be able to get to work with the newest data.

    •  
  • Intralink 3.x fast preview removes the need for all those old bitmaps, you can delete them. But first turn off all the 3 config.pro settings which include the word "bitmap". Then watch out, because if you delete a bitmap in the Commonspace while the part is checked out in a Workspace, you can't get rid of the relationship with Modify Relations, you actually will have to Export the part out of the Workspace and then Import it back in again, before you can submit it again. So don'g blindly purge bitmaps.

    •  
  • Folder Replication includes every version of every object. Now one of the biggest Intralink performance hits is running over a WAN. But to avoid that, you can create a local filevault, then copy the files over the WAN just using FTP or whatever other operating system utility, and then move the filevault.

    •  
  • ldbcompact is an Intralink bin utility which you might include in the client startup script, or which you might just run every couple of weeks. It will usually reduce the local database by a large amount, for example, from 1.2MB down to 70KB.

    •  
  • the Briefcase is a good tool to gather any miscellaneous collection of files to checkout, or to create a new baseline.

    •  
  • As Stored baselines become As Stored configs in 3.x (the migration to 3.x will take care of that in the conversion). As Stored configs are built dynamically, meaning, the config uses whatever it can find. Like the latest version, if it can't find the original version. This makes the As Stored config more robust than the As Stored baseline, less likely to fail because a particular version is missing. But on the other hand, you may end up with a later version than the one you expected.

    •  
  • Intralink has a transaction ID for every object. But each object also can have any number of secondary transaction IDs. When an assy is checked in, the changed files all share the same transaction ID, but the other files (that belong with the assy but which were not modified this time) get a secondary transaction ID. So Intralink knows the difference between the files that were checked in, and all the other files that are required for the config but were not modified in that checkin.

    •  
  • if you are at all serious about data mgmt., don't rely on the As Stored configs, create your own baselines. If you're making baselines, you probably want them protected, otherwise the baseline can be deleted.If you create baselines, be prepared to manage them through the product lifecycle.

    •  
  • 3.x has good tools for working with tables: drag and drop headers, one click sort, Shift & right mouse click on header to autosize that column, and Control & right mouse click on one header to autosize all columns. And if you want to lock the first column, while you change the other columns, you can do that by dragging the vertical divider below to the right of the first column: then what you do with the other columns won't affect that first column.

    •  
  • some companies use custom Intralink Toolkit applications to kick Intralink data over to a MRP system. However a reasonable alternative is just to copy a report, then use Excel or another spreadsheet to massage the output for the MRP system.

    •  
  • if you change Oracle servers, or change your dataserver, you do have to do a manual migration, can't use ptcsetup.

    •  
  • people running more than one version of Pro/E can get problems with workspace Import and Export. Solution here is the edit your Intralink script to only have a path to the particular Pro/E version you want to use. May mean creating several copies of the script, if you really want to use Intralink with several different versions of Pro/E at different times.

    •  
  • creating Intralink trail files is expanded in 3.1, very similar now to creating a Pro/E trail file. And you can step through the trail file, one step at a time. The trail file itself is a .java file. The trail file GUI works to bulk load files.

    •  
  • Intralink and Pro/E talk a lot, because Intralink communicates the commonspace status of every object to Pro/E.

Core Modeling Tips and Tricks


This late afternoon session was quite well attended, even though HP did their best to distract people by busing over 200 users off to a nearby racetrack as the session began.
 

  • if your initial datum planes are ludicrously large or small for your requirements, that's probably because the default size is 900 units. If that doesn't work well for you, go to your start part (of course you're using a start part), select a datum plane in the model tree, and Define the Fit Radius to be a number you like. Do each datum plane, but since this is the start part you don't need to do it again.

    •  
  • ISDX surfaces default to freeform surfaces, but you can use exact values too.

    •  
  • when you create formed text in the sketcher, drag the text location straight up: then the text you create will appear to the right of that line, and read left to right (and not upside down, or right to left, common problems).

    •  
  • when you form text on a surface, it'll only work if you have a "developable" surface. Turns out a developable surface is a surface which can be flattened out without deforming it, like a cylinder or a cone. You can check if you have a developable surface by looking at the Gaussian curvature: a developable surface is a solid color, while other surfaces are rainbows of colors. If find you have the rainbow type surface, you can redefine the Surface Type to make it developable. It will be split up into smaller surfaces, but they will accept formed text.

    •  
  • you can use UDFs for assemblies, as well as for parts, you'll get prompted for the references.

    •  
  • small breaks in an outline can cause Geom Checks. You can convert different entities, like arcs, to a spline. Or use Approximate Composite Curve, which will convert everything in the outline to a spline. But, don't use Approx. Comp. Curve to redefine existing geometry.

    •  
  • when sharing design intent with other groups, like Mfg., Inheritance Feature lets you easily create a new part which you can edit to leave out unnecessary info.

    •  
  • there is a neat way to identify gaps or overlapping segments with quilts. I didn't quite get the details, but it's something like an edge collection sweep. The command highlights the problem areas with green points.

    •  
  • you can fill holes in a collection of quilted surfaces with Surface Copy > Quilt Surfs > Fill.

    •  
  • you can edit the standard holes feature list on 2001, including the exact text of the hole callout (but not apparently to any drafting standard). But you do need to set hole_parameter_filter_path in your config.pro, so Pro/E can find that file.

    •  
  • you can convert imported geometry to a Pro/E sheetmetal part, to unfold it for example, just as you convert a Pro/E solid part to sheetmetal.

    •  
  • assembly constraints can't handle everything. For example, a single point tangency, like a sphere touching an edge. But you can create an assembly feature, like a literal datum point at the point of contract, and use that. Similarly, if you have a spherical surface tangent to two other surfaces, you can just offset them each by the radius of the sphere, and their intersection will give you the centerline of the spherical surface.

PTC Intellectual Property


The next presentation, Top Down Design, with Howard DeRuyter from PTC, was visibly enriched because Howard has just completed two solid years working at Boeing Satellite Systems in L.A. And Howard was part of a PTC team there working to adapt Top DOwn Design to satellites. So there was a good amount of practical detail developed by the team, which Howard passed on to us.

You might wonder, how many different PTC teams around the world are trying to figure out Top Down Design simultaneously? I wondered that too. Well, Howard explaind that the Services group at PTC is apparently working now to collect and interpret the experience of PTC field consultants on subjects such as Top Down Design. In the case of TDD, that could lead to a new edition of the Top Down Design Guide, which is probably overdue now.

PTC has always been encouraging us to organize and document and save our intellectual property. But PTC certainly has intellectual property of their own that they could organize and document and save too. For example, the knowledge of sales reps. about their different accounts. If you've had contact with any number of PTC people, you've probably ended up telling the exact same story about your company and what you do to each PTC person in turn. Everyone could save a lot of time if they just recorded your story once, and then anyone else you met from PTC could check it in advance.

Just the same way, the world-wide experience of PTC consultants down in the trenches with customers making the software work is a huge possible resource, first of all to PTC themselves, but then also to other customers. Perhaps if we see a new edition of the Top Down Design manual, visibly invigorated and inspired by hard-won field experience, then we'll know that PTC is working on the intellectual property from the field too.
 

Top Down Design


Howard DeRuyter began his talk with a stimulating statement: the way to begin Top Down Design is to turn your computer off, to stop and think. And, if your computer is off, it follows your tools will be pencil and paper. That sounds right, that is the usual initial stage of design, computer off, pencil on. No matter how big or small the project. Howard compared this phase to the initial phase of software programming: a software programmer can't just jump in and start writing code, they have to plan it out first. Same for a Top Down Design practitioner.

Howard described Top Down Design as basically "a planning and coordinating activity". The Pro/E work will implement the plan, but the plan has to be there to guide the Pro/E work, for an activity like Top Down Design. Then Howard suggests using a tool "like Excel" to document the initial plan. The plan obviously will vary by circumstances, but two general topics Howard mentioned are (1) Define Design Criteria, and (2) Define Preliminary Product Structure. A huge advantage at this point is now you have documentation you can share with anyone interested, before you start Pro/E and begin to commit yourself one way or another.

OK, then now we've turned the computer back on again. But there had to be that moment to stop and think initially. The Prelim. Product Structure has to take into account probable changes during the design phase, you have to assume it will change, build that in.

Skeletons can be used for space claims (often surfaces), interfaces (surfaces and datum geometry), or motion simulations (datum curves). But in any case they'll be developed from the product structure already documented. Assemble skeletons directly into sub-assemblies, so you can refer to them directly, not a Copy Geom. Or, another technique is to use Publish Geom to prepare different packages of skeleton info. for use in subassemblies. When skeletons drive geometry, simplified reps. are much easier, if you include the skeleton you don't have to be so concerned exactly what you include in the simplified rep.

As well as having a top-level skeleton, which could include separate driving skeletons assembled into one master skeleton assy, you can also have multiple skeletons further down, defining the interfaces between pairs of subassemblies---trying to stuff everything into the top-level skeleton can be too much. So, you might have a skeleton at the sub-assy level to define interfaces between subassy A and subassy B, and another one to define interfaces between subassy B and subassy C, and so on.

Copy Geom has to be a common way to copy geometry within an assembly. But Howard thinks the difference between the old standard Copy Geom and the new External Copy Geom may not be well understood, and it's important.
 

  • standard Copy Geom follows the entire path within the assembly between the target part and the source part, and saves and depends on all those references. For example, if the target part is buried 3 subassemblies deep, and the source part is buried 3 subassemblies deep in another branch of the assembly, then doing the copy geom will create a chain of at least 6 references. Which will follow that part forever, and if there's ever a problem with any of those 6 references, that's it for the feature, and for the part too. And you do need all the other 6 subassys in session, just to regenerate the Copy Geom feature.

    •  
  • External Copy Geom eliminates the entire train of references by just using the coordinate locations of the source and target parts, to determine their location and orientation. So, with External Copy Geom, there's just the source and the target, that's all, no more references. You only need these two parts in session to regenerate the feature. The only limitation here is that you need to have had the foresight to create a common coordinate system for the assembly.


Howard recommends creating a top-level common coord. sys. for any assembly, not just for satellites and spacecraft. Certainly a single coord. sys. is normal for cars and truck and locomotives and aircraft, so, has support.

Whether you use an Ext. Copy Geom, or you reference an assembly skeleton, probably depends mostly on how you expect a part will be used. If you expect to bring it up by itself alone, with a minimum of other parts (perhaps just only the source part), then an Ext. Copy Geom is appropriate. But if you expect to bring it up always in the overall assy. context, then you will probably want to get the critical common information, the information shared with the Copy Geom source part, from some skeleton that both parts use.

A couple of tips:

  • to have multiple skeletons at one level in an assembly, you need to set multiple_skeletons_allowed to yes (now there's a self-evident config.pro setting).

    •  
  • naming key features has always been useful. And now it's pretty easy, just open a Feat Name column in the model tree. Just type in new names on the fly as you go, you don't have to do Setup > Name > Feature any more.


A good question from the audience was if you're paperless, and have no drawings, how can mfg. and other end users still see dimensions in the part, if the dimensions are from a separate skeleton? Best answer seems to be, if you do want an independent part file which has the dimensions in it, then merge the skeleton into the part (or even better now, do an Inheritance Feature, and select just what you want of the skeleton).

And a warning from the audience was that if you use skeletons to pass information both ways, down and also up, within the assembly structure, you can create some really difficult circular references problems.
 

Design Templates


Howard in the previous session mentioned how after first thinking about a new product design, then you might represent it in Excel or a similar tool.

So, why not some Excel templates for the Top Down Design Pro/E user? Something that would guide you to document your proposed Pro/E assembly structure, before you ever fire up Pro/E.

PTC could provide some particular tools to use before you use Pro/E. But most anybody else with a good idea could probably contribute too (perhaps make some money too). At this early stage, it's ideas and relationships that need to be caught, documented. As Howard said, using plain Excel would be one way, doesn't have to require any kind of graphics programming or similar work. Tools to document design intent and product structure at this early stage, the pre-Pro/E stage, could be very powerful and valuable, but also pretty simple. Graphics programmers need not apply.

So, that's that suggestion, perhaps we could have a session next year on the tools/templates/procedures you can use before you ever start using Pro/E.
 

Peter Nurkse
Sun Microsystems
peter.nurkse at sun.com