Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Best types of assemblies

Status
Not open for further replies.

bjzion

Agricultural
May 26, 2005
5
0
0
US
So, I have been searching for explanations on different types of assembly methods and can't find any good information. I am interested in the pro's and con's of using the following types of methods on a large vehicle design with many many assembly options. I am afraid that I will be limited to using unique sub-assemblies for each option we have, but want to make sure I am not counting out other methods. I am currently aware of the following:

Multiple assemblies with common cord sys. When used with Sim Reps, seems to be pretty powerfull. I am afraid that I will end up with 100-150 individual assemblies which may take time to update.

Multiple assemblies with Skeletons: I am a little gunshy about skeltons. They don't seem to offer any advantage over option one (especially when using mechanism) just more overhead in keeping the skeltons up and running.

One big assembly and Pro/Program: I don't know much about this, but am not sure if keeping 10 sets of 50 parts (some used in multiple sets) at various positions will benefit my sanity.

Family tables: seems to be a similar situation to Pro/Program

If anyone has a solid opinion on the good, bad, and ugly of these, I would love to hear it. I have done a little searching on the internet but not found an all inclusive article; if one is available, I would appriciate a link. Looking forward to available advice.
 
Replies continue below

Recommended for you

First things first, you would have to deside if your design lends itself to be Top-Down or Bottom-Up. This will dictate what Pro/e assembly functionality you will apply to the design.

Multiple assemblies with Skeletons: I am a little gunshy about skeltons. They don't seem to offer any advantage over option one (especially when using mechanism) just more overhead in keeping the skeltons up and running.

Bottom-up :component parts are designed and edited apart from their usage in a higher assembly.
1.Create part solid models.
2.Combine parts into sub-assemblies.
3.Combine sub-assemblies into assemblies.

Top-down :the hierarchy of assemblies and sub-assemblies is designed first,then part solidmodels are designed in place.
1.Create highest level assembly.
2.Add empty sub-assemblies and parts to assemblies.
3.Create solid models in empty part files.





Best Regards,

Heckler
Sr. Mechanical Engineer
SW2005 SP 2.0 & Pro/E 2001
Dell Precision 370
P4 3.6 GHz, 1GB RAM
XP Pro SP2.0
NIVIDA Quadro FX 1400
o
_`\(,_
(_)/ (_)

Do you trust your intuition or go with the flow?
 
We are pulling older desings into Pro/E. To to this, we are starting with creating parts from drawings and then putting them into assemblies. A bottom up type of design. Can you explain to me why it makes a difference?
 
Bottom-up design does not allow for the system level functional relationships to be formally captured early in the design process. Bottom-up design is especially difficult with large projects and vendor developed items. You expose yourself to being depended on the eventual solid models from vendors (or employees) to have the "big picture" of the eventual product with bottom up design. For example: An automotive suspension system (simple four-bar linkage) where you are responsible for the system's performance and integration, but not the detailed component design. The kinematic and dynamic modeling and simulation can take place without the detailed eventual solid models with top-down design by creating a kinematic skeleton (using datum geometry and simple primitive surfaces and solid features capture the engineering content). The solid models can be "hung" on the skeleton framework with all the kinematics already in place. Also, for components like weldments, we use TDD to capture the structural concepts, perform structural analysis on this model and then use it as the template for the subsequent down-level parts. Try thinking about how hard it would be to change the thickness of a part in a weldment without requiring other parts to be automatically changed to accommodate the change. I can think of probably a hundred reasons to use TDD; even with legacy parts to be included in an assembly. You need to have the flexibility to swap out parts (or features) and maintain the design intent. Bottom-up design will never allow for this.

Hope this helps.

Best regards,

Matthew Ian Loew


Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora.
 
Ok, I see the advantage, but have a few more questions. I assume that for the base geoemetry, you are using simple parts with datum curves to capture locations of design. Is there any special way that you name these parts? I have been doing some of this with an _crv appendix to note the differences between actual and base parts. Is there a better way?

Also, I have been building my models with a Master_Base model that has all the connection points for the subgroups (we have about 8 of them) instead of using skeletons. I just don't appriciate the knowledge base required to utilize skeletons and think I am getting the same functionality with a single base model. The only advantage that I see ist that if sub assembly has a lot of datum point/curves it could get crowded. Is there something I am missing?
 
Skeleton models are treated a little differently than regular part files, so it is sometimes a better idea to use them. I have used regular parts (as you have) in situations where I was working with licenses that didn't allow for skeletons.

Skeletons are not included in Bill of Materials reports or mass property calculations (if they are just datum featres it wont matter). Many part templates contain layers for skeletons as well, making them easier to blank out.

They also show up with a different icon in the model tree, but like you I append their name with _SKEL or some other distinguishing name.
 
I have also seen where skeletons can be named and/or programmed to control geometry. This seems to be a benefit, but I can do the same thing with Mechanism - and a lot faster.

Maybe I am not keen on skeletons since our envirenment isn't structured to take advantage what it offers. Am I missing anything on this?
 

Something that should be interjected regarding utilization of skeletons and the overall TDD approach is the capability to drive your design (and its permutations) by means of a layout and parameterization. The layout is defined in Pro/E as an upper-most level in the TDD within which you establish and control the major design characteristics for you program. Generally it consists of an illustration to help identify those major features, as well as data tables that actually drive the design. These tables are populated by parameters, defined to control your key characteristics. Individual parts, assemblies and skeletons are "declared" to the layout, which then allows the layout's global parameter values to drive their size, position, etc.

One commonly used analogy is that of an engine design. Primary characteristics like bore size, number of cylinders, displacement, valve positions, and so forth can be defined by the parameters mentioned in the table above.
As the design evolves, the layout provides a central location from which to alter all of the downstream components and subassemblies, thereby reducing the potential for mis-fits just because someone forgot that changing the cylinder bore size required a corresponding change in piston diameter (for example). Since access to modify the layout is generally restricted to the project lead, unauthorized "tweaking" of the primary design dimensions is avoided also. Which means that to change a part that is controlled by a global parameter, the modification needs to be done in the layout. So you maintain control of your connecting rod's pin to crank length, pin & journal diameters, even though the subcontractor who's working on that part design has the freedom to optimize the rest of the part's geometry.

Overall, a very powerful tool that can help to organize and control the most critical project characteristics and allow them to be communicated thruout your business to keep all players supplied with the most up to date data.

Ed Leitkowski
 
Status
Not open for further replies.
Back
Top