Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Register Log in

Top Down Design: Specifics

MartinH

New member
I understand the principles of Top Down Design theory, and tend to follow them in my own designs. However, for all the discussion about the theory, I haven't been able to find any specific information about how to lay out a Pro/E project to follow the principles.

I reviewed the tutorial that was posted in this thread, but it doesn't really do anything special besides controlling external references and assigning a few dimensions with relations. I can't imagine that's all there is to it.

What I would expect to do is create a part or assembly (skeleton perhaps?) that contains planes, axes, and sketches representing key geometry in the design, then each part and sub-assembly would only reference that geometry. Is this a reasonable approach or are there better ways?

There is also a question of how to lay out the project to do this.

For example, how do the components reference the geometry from top level? If I just work in the assembly and activate the component I want to work on, I can reference the geometry directly, but that means afterwards I can't work with the component without the assembly. It is also possible to copy the geometry into the component (Insert -> Shared Data), but this creates a single item in the feature tree called "Extern Copy Geom", which is not very convenient to work with.

What purpose do skeleton models serve? I understand what they should be logically, but not how they are any different than normal Pro/E parts.


By the way, I'm using Pro/E WF2, and while I've spent a fair bit of time using the program and learning what I can from books and the internet, I have no formal training with it.
 

SW

New member
Skeleton models behave differently in that you can use the reference
control to only allow skeleton parts to be referenced. There are
probably more important differences that I don't know about.



Sam
 

jeff4136

New member
Martin, do you have AAX? The methods will differ in execution depending on whether you have it or not. In essence you can do most things (subjective) well enough without it. PTC's documentation on the subject assumes you do have it, though (correct?).

"... but that means afterwards I can't work with the component without the assembly."

Not true, but there's a config option that must be set. (Actually, think there are a couple that either allow loading without parent or automatically bring parent into session when child is opened?)

"... but this creates a single item in the feature tree called "Extern Copy Geom", which is not very convenient to work with."

Hmmm... I guess that means you do have AAX as Copy Geom functions are limited or non-existent without it. There are other methods of copying references though. Looking into them may be beneficial even when the functions are available.

Don't know, myself. Don't have AAX. It would be nice to see PTC (or anyone) focus a bit on documentation of top down methods where AAX is not used.
 

MartinH

New member
Thanks for the suggestions. I think I have a better grasp now, though it seems that the actual procedures are not much more complicated than I originally thought.

james.lynch:
The tutorial you posted, along with the advice in this thread provided a good, short outline of the methodology. Thanks.

jeff4136:
I assume I must have AAX, since I can use skeleton models and publish geometry, though I can't find it specifically listed in any of my license info. To be honest though, I don't see that they add so much to the TTD methodology. They provide tools to help you restrict your references, but even without the tools, you can still follow the restrictions.

The skeleton models provide a nice central place to store geomtry for assemblies, but the geometry can be stored right in the assembly too. Publishing and copying geometry are nice logical ways to share geometry, but anything shared ends up as a single item in the feature tree, which makes it very hard to use in complex projects.
 

james.lynch

New member
jeff4136 said:
Don't know, myself. Don't have AAX. It would be nice to see PTC (or anyone) focus a bit on documentation of top down methods where AAX is not used.

Jeff,


I'd be interested in hearing your thought on top down modeling without AAX. I have recently started some projects without the use of AAX but still employ top down techniques using the "Master model" technique - which involves quite a few surface copy's.. it's a little different to what I'm use to..


or indeed if anybody has anything to add?


James
 

jeff4136

New member
Hi, James.

I'm not sure I have any really worthwhile thoughts on the subject.

For me "top down" falls into two catagories;

(1) I'm building around / interfacing with an existing (usually imported geometry) assembly. I'll simply reference the given geometry to create datums, sometimes copy some sort of geometry (faces for contours, etc.).


(2) starting with nothing more than an idea. A "master model" approach where one or more master parts contained defining geometry was a staple in a system I used prior to Pro/E. The masters would typically contain sketch geometry, datums, maybe surfaces. Master driven component parts would then be created by the equivalent of Insert / Shared Data / Merge as a first feature and assembled by the equivalent of aligning default csys.

Since picking up Pro/E I've abandoned the "master part" and have been simply creating the basic driving geometry in the top level assy where it is may be referenced, copied, etc. This seems to work well enough.

My concern is: I don't know how this will all wash down the road. Any method of creating dependancy chains has trade-offs in performance and reliability, pitfalls and gotcha's (as does any complex system). Though I endeavor to keep dependancy chains clean / robust / recoverable there's so much that goes on "behind the curtains" I have no idea what the big picture looks like and there's little in the way of guidelines, best practices, suggested methods to start with. (One of the less intuitive things I've recently discovered: Showing assembly features [cuts, holes, etc.] at the part level is more resource efficient than showing at top level only.)

No major burns so far, so guess I'll just keep acting like I know what I'm doing.
 

Sponsor

Top