pros and cons of top down design

[sanjeevkar1]

hi all


one more question.





what are the pros and cons of TOP DOWN DESIGN

 

[CPiotrowski]

The pros: If youbuild it correctly, its much faster to edit and change models and features. Its the best way to model a very complex assembly.


The cons: If you built it wrong or without keeping modifiability in mind, it will end up just being a big waste of time. Your skeleton will be useless and all the time spent on making the skeleton will be for nothing.

 

[Mindripper]

Do you have to use a skeleton model? I typically just start creatiing models in assembly mode, then breaking the relations quickly - and re-establishing them or creating new ones as required. This is serial in nature, but very productive if you can keep track of things. But it's challenging to maintain the global design intent when more than a few dozen parts are involved in the conceptual layout.


The skeleton model strategycan bemore limiting in it's flexibility. But even a simple assembly with complex surfaces requires a master model.


As with sketches and features, minimize and control parent/child relationships as you develop the design, or you risk creating a spider's web of gnarly interactions. Complex assemblies or surfacesand multiple designers building a common database are better suited to skeleton and master models. If it's a fairly simple creation controlled by a single user, the user is probably better off without a skeleton model.

 

[gkbeer]

One man jobs can get by without top down design, as long as they stay "one man".

The only problem is that most jobs start out as "one man jobs". Then they turn into multi person jobs - and there you are trying to explain your modeling techniques, having to restructure your assemblies, all so you and the new guys aren't stumbling over each other. Yada, yada, yada.

If you don't develop a job from the start with Top Down Design Management in mind, it's almost impossible to implement it later. The job won't wait while you stop and implement good multi user organization.

There is a good guide called the "Top Down Task Guide" written by PTC. It used to be available as part of the Pro/E install. Search your loadpoint for PDF files and you may find it.

 

[krahmk]

Skeletons are an improvement over master model in that your proprietary data is more secure. With master model, your entire mastermodel goes out with your file even if it is just a tiny piece of the overall assy. Using STEP files instead of Pro/E files does eliminate this, but if your vendor prefers Pro/E, they get it all

 

[Mindripper]

There is a devious way to use a master model WITHOUT sending out the master model with it. I'll have to check my notes from eight years ago on how to do this, but it is possible. Perhaps the epitome of the 'smoke and mirrors' that Pro/E is capable of. I still don't fully understand how this works, but I know that it does work, as I used it a number of times.

 

[dgs]

One man jobs can get by without top down design, as long as they stay "one man".

Actually, I think there are benefits to 'multi man' jobs by using skeleton driven design. Consider the following scenario:
<UL>
<LI>Assembly A with sub-assys 1,2 and 3.</LI>
<LI>Project manager creates top level assy and the 3 sub-assys. he adds a skeleton to each. </LI>
<LI>In the top level skeleton he creates the geometry that needs to be shared by all sub-assys.</LI>
<LI>He creates publish geom features in the top level skeleton for each sub assy and then adds copy geometry in each sub assy skeleton referring to the appropriate publish geom.</LI>
<LI>He takes responsibility for the top level assy and sub assy 1 and hands off sub assy 2 and sub-assy 3 to other engineers.</LI>[/list]


Those engineers now have everything they need at this time to develop their sub assys and tie them to the master. They can build on the copy geom from the top levelin their skeleton and add features in their subassy skeleton for items that only apply to that sub-assy.


If the top level skeleton changes, including the addition of new feature to the publish geometry, the engineer can open the top level assy and regenerate. This will pass the new and updated information down to their subassy skeleton.


Yes, it will take communication and planning, but that's true of any project. What the skeleton can co is provide a means within Pro|E for the project manager to communicate design intent and design detail to the others on the project.

 

[prohammy]

Sanjeev,


I could take hours on this one, but I'm going to go for brevity...


Pros


1. Control of your design is much simplier
2. Multi users on one project is controlable.
3. Parts are developed with reference to the overall assembly, not as standalone items. Consequently, it is very easy when in the design phase to leave parts that can adjust as the skeleton adjusts.
4. Assemblies are all related to a single default CYS (using skeletons)


Cons


1. Very easy to create external refs and circ. refs. (Relies on the designer taking a very methodical approach to his/her design)
2. Transfer of work to drafters can become complecated. Explaining the how, why and whata skelton does can be quite time consuming.


Overall, after a number of years working in 3D CAD systems, I will always choose to do top down designs....BUT there are cases where I will have to bottom up as well (often in the same project).


Conclusion.....you gotta know how to do both


Kev

 

[sanjeevkar1]

thanks Kev and everyone for the answers.


if someone ask me; i always prefer top down design when making large assemblies (1000+ parts) but when working on small assemblies (-50 parts) and i know they won't change, i use bottom up approch.





ummmmm i love bottoms up

Edited by: sanjeevkar1

 

[dgs]

...and i know they won't change ...

I want one of those projects. Haven't seen one before. Oh, I've had onewhere I thought things weren't going to change, but it never turns out that way.


I use top down on everything. Sometimes it drives folks here a little crazy, but when big changes are needed late in the process and I get it done in hours not days, they are grateful.

 

[dougr]

All this talk about Top Down design and no mention of "External References". Can you imagine the amount of ext refs you could have in 1000+ assembly ???


In the real world some things can only be designed as "Top Down" such as pipe/cable/ wire runs, welds etc, etc

 

[SRINIVASANIYER1]

I look at it this way.


A vehicle has both an Accelerator and a Brake. We cannot choose between the two. We need both. A judicious application brings in CONTROL.


It is this control that is important.


A complete TOP DOWN design is OK where you are not going to use the parts for any other project. For common parts used accross the projects, a Bottom Up approach is preferred.


Hence the concept of Accelerator and Brake to achieve control.

 

[sanjeevkar1]

i agree srini

 

[prohammy]

All this talk about Top Down design and no mention of "External References". Can you imagine the amount of ext refs you could have in 1000+ assembly ???

Hey Doug,


Take a look at my post earlier and there is a mention of external refs. I have run into problems with ext refs a few times with various different companies I have worked with. They generally cause no end of grief with PDM systems (especially when you are not using PTC's). One company I worked with used ModelCheck to make sure that no model could be sent to the PDM system with an ext ref.


Kev

 

[dgs]

Ext. refs are not evil, but they need to be managed and planned for. Some companies have a 'no ext. refs' policy, which I find is unfortunate. They will have an easier time with data management, but loose out on the time saving & error prevention benefits of TDD.


Srini's point of knowing when a part is going to be re-used is a good one as well. If a part will be used across many assemblies, you likely don't want it tied to one of them.


You've got to plan ahead.

 

[Mindripper]

External refs should be to the master or skeleton model, not to a chain of components across multiple assemblies. This is what they are for: to help the user (or the team) retain their sanity. Be sure to break non-critical external references as soon as possible. If features need to be tied together on adjacent models, try to do it through a feature in the master or skeleton model, even it's a single datum point added to the master or skeleton model. It's nested levels of external references that result in mental illness.

 

[dgs]

External refs should be to the master or skeleton model, not to a chain of components across multiple assemblies. ...It's nested levels of external references that result in mental illness.

Absolutely. A component should reference the skeleton in the subassy it is apart of. That subassy skeleton gets info for the upper level assy and so on. In this way, each assy & sub assy can 'stand on its own' so to speak. and the only place data enters the sub assy is through the sub assy skeleton. This keeps things neat and organized and pretty easy to follow.


It's when parts start getting data directly from other parts or from the top level assy skeleton, skipping levels in between that you start having headaches. Like every rule, there are exceptions to that, but they are few.

 

[gkbeer]

External refs should be to the master or skeleton model, not to a chain of components across multiple assemblies. ...It's nested levels of external references that result in mental illness.

Absolutely. A component should reference the skeleton in the subassy it is apart of. That subassy skeleton gets info for the upper level assy and so on. In this way, each assy & sub assy can 'stand on its own' so to speak. and the only place data enters the sub assy is through the sub assy skeleton. This keeps things neat and organized and pretty easy to follow.


It's when parts start getting data directly from other parts or from the top level assy skeleton, skipping levels in between that you start having headaches. Like every rule, there are exceptions to that, but they are few.

Oh My! What a hot button this pushed.

I've been there where there was a strict passing step by step top to next to next...

It didn't work well. If the rep I was working in was missing even one reference in the chain, the features in the lowest level skeleton didn't update.

I much prefer the arrangement where copy geoms reference their source as directly as possible. Preferable that reference is a publish geom. That way they will update with a minimum of items in the rep.

Skipping levels means I can restructure the lower level assemblies with minimum fear of failed references.

 

[sanjeevkar1]

i think the best way to work with TDD is using publish geometry.


there is a master assembly containg a master skelton. that skelton should have publish geometry for all the subassemlies.


these subassemblies should have their own skelton containg the publish geom and other features required by that subassy........


i think this way the model is more clean and with less problem

 

[dgs]

The publish geom is definitely the way to go. When changes come, redefine the publish and regen the assy. Done. Also, if references are missing for the copy, the publish fails in the skeleton where it;s easier to fix. The downstream copies are looking for one thing only - the publish geom.


Glenn, I agree that missing references in the copy geom is an issue. It's an all or nothing approach the way it's configured now. If one item in a copy of 1,000 items fail, the other 999 are frozen. Using a publish geom as stated helps that.


My biggest issue with copying down front he top level directly to the bottom is the sub assys in between don't have all the data. For example, if I have assy A with subassy B and subassy C within B. If I copy from the main assy skeleton in A to a component in sub-subassy C, then when I open sub assy B it doesn't have all the data to regenerate it. There may be multiple things (components, sub assys)that are missing copy refs. If each subassy has its own skeleton feeding it's components and subassys geometry, then only that subassy is missing a reference. The rest of the things (components, sub assys) have what they need.


I see your point about restructuring, though. With my method, restructure isa bunch harder. I've had some mixed successes redefining copy geoms to refer to new publish geoms in other models, but that can be asking for trouble.