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

Large Similar Assemblies

denncoa

Member
Hello All;

We are currently in the process of setting up intralink and trying to make full use of Pro Engineer 2001. We currently produce an airplane that customers can purchase with different options. Essentially the final assemblies are very similar with only a few minor differences. We are not sure exactly how we want to manage these assemblies. (we have not created these large assemblies yet) Do we create one assembly and then a family table with different options? Do we create multiple separate assemblies? What are your thoughts, positive or negative? Thanks

Denny Coauette

Cirrus Design
 

dougr

New member
First-things-first.



Establish a critical parts list first with all of the common parts/assemblies.



Beyond that you can decide whether to use family tables or generic assemblies, however you should follow your Company product structure. How does your Company identify the different assemblies - with a core # plus counter (******-001) or do they assign completely new core numbers ?



If the former is true then Family Tables are a good candidate, if the latter is true use separate generic assemblies.
 

forster

New member
Our company manufactures motorized storage machines that consist of very simmilar part lists at the top level. Using family tables of parts, subassemblies and large assemblies allows the designer to easily replace an instance for another and to create nested family tables for like configurations.



I would very much recommend a top down approach, making use of skeletons as much as possible to capture design standards and design intent.



A family table can easily capture parameters such as part and model numbers.
 

mmead0ws

New member
Here is a list of gotchas with Pro/INTRALINK and family tables.



Please limit the usage of family tables with Pro/INTRALINK. If you don't, Pro/INTRALINK performance will suffer.

Don't use the generic of a family table in an assembly.

Don't use family tables of assemblies with Pro/INTRALINK. Family tables of parts are fine.

Don't nest family tables in Pro/INTRALINK.



Here is why.



Although Pro/ENGINEER creates one file for a family table, Pro/INTRALINK treats each instance as a unique part. If you check out a family table, you get the generic and all the instances. This could be a hundred plus sets of metadata just by checking out one Pro/ENGINEER file.



Say you want to modify a part family table. PTC recommends always checking out and verifying all family table instances when updating a family table. In the past, this recommendation has been manditory or optional based on certain criteria. PTC doesn't make any assurances if this recommendation isn't followed.



For example, if you are making a dimensional change to one family table instance, just check out that instance and the generic. If you are making a change that in any way affects any other instances in the family table, you must check out the generic and all the instances in the table to make the change. As a change is made and the file is saved, the generic and the instance versions are itterated. If your company tracks files by itteration, the generic itteration will bump up any time any instance is modified.



Family tables can include up to a few hundred instances. Suddenly a quick change can make check-out and check-in into a coffee break ordeal.



If you have family tables of assemblies, the number of files checked out grows exponentially. If you really want to run Pro/INTRALINK, don't use family tables of assemblies.



PTC recommends using family tables for library components (fasteners, etc). Typically fastener libraries in Pro/INTRALINK are read only to the users. One person, in most cases an administrator, is in charge of updating the fastener libraries as new components need to be added. This minimizes the check-out/in load on designers. Designers can check-out only the components they need to use and not the entire tables. Many companies don't use family tables at all with Pro/INTRALINK, not even for fasteners.



Pro/INTRALINK only supports family tables up to three levels deep. Pro/ENGINEER itself will handle assembly constraints differently beyond three levels deep even without Pro/INTRALINK. For designers, it is more difficult to track down instances of a nested family table. In addition, the same versioning issue occurs with not only the generic, but with every nested level down to the instance(s) being modified.



There are other methods of building your product without extensive use of family tables. I'll explain some options in a separate message.
 

mmead0ws

New member
1. If the assembly reference IDs are the same between two components, they can be replaced manually and will automatically replace. Some companies originally family table their fasteners only to break up these family tables into individual Pro/E files. They do this to get better performance out of Pro/INTRALINK. Because all components came from the same family table, they all have the same geometry IDs and can interchange quickly and easilly.



2. Pro/ENGINEER Wildfire released internal component references. If you download any bolts from the on-line PTC PartsLink library, these components already have component placement references inside them. If you drag and drop these components on top of a hole where you want them to assemble, most of the time they assemble themselves. It is still new technology and the auto-assembly hit rate should go up as the technology matures.



3. Interchange assemblies can be used to make totally dis-similar parts/assemblies interchangable. Most long-term Pro/E users complain about interchange assemblies being hard create. But I have never had any problems creating or using them in the latest releases of Pro/ENGINEER. Pro/INTRALINK will check out the interchange assembly and all the associated assemblies if you request to check out all dependencies.



4. Layouts can be used to maintain references between interchangable components. If a series of components have identically named placement references ('asm_axis', 'mate_datum', etc), a layout can be used to capture these references for interchangability. Please test this, but I believe the layout method only checks out the assembled component and the layout.



5. Another fairly new technology (2000i2) is the inheritance feature. Inheritance features are one-way associative links. It is like a copy geometry, only better. They were created to replace family tables with single instances (Cast part vs a machined casting for example, or a sheetmetal bent state vs flat state). However, they are interchangable components.



6. There is always the manual replace method. It may be slow, but if it is a one-time deal, it may be faster



If your sub-assemblies are similar, use Pro/INTRALINK to copy them to new names. Then make your modifications to the new sub-assemblies. If the IDs of their assembly refernces don't change, the will interchange manually without any effort. If the IDs of their references do change, use one of the methods described above to interchange them quickly and easily.



Simplified Reps do help performance. But they only affect the ammount of required RAM while the model is in session. They have no affect on the interchangable components in your assembly. Use Simplified Reps in conjunction with skeletons to get even better memory utilization.



For example, if you include a component in a simplified rep, but not it's parents, Pro/ENGINEER will maintain the parent components in memory even if they are not shown on the screen. If your components are assembled to the skeleton where possible, it reduces the number of required components in memory when using a simplified rep.



If you want to automate the replacement of your similar components, you can use Pro/PROGRAM. The coding changes according to the component type (family table, interchange group, etc). So use Pro/HELP and the Knowledge Database as references. The Knowledge Database has many how-to documents for implementing all the above methods.



Sorry for the long winded message. Hope some of this helps.
 

guruprasad

New member
Guys,



The variant creation in PRO/e is best suppourted by an bit of amazing application called DDL-Link which is spilt of windchill.if you are into variant creation where the customers has something to vary I think this is the tool which you should look at & even ask for demo on this..



I was amazed to see this new technology which has come handy for our compnay where we manage these variants very effectively & creting exact BOM



Happy Living

Guru
 

Sponsor

Top