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

Relations in family tables

SW

New member
I have created a part that has two family table instances. I
want one of the dimensions in the family table to be controlled by a relation
that uses a dimension from the assembly the parts are in. While this in itself
is not a problem, I want the relation to be different for each of the instances
and can
 

xcad

Member
how can that be done...


the family table is based upon the possibility the same dimension to be changed in each instance


and know we want in this dimension that is changing in every instance, to assign a different relation...


i think that we cannot do this... makenew part and assign the different relation there.. do not use family tables to do this....it is not the right way....



Edited by: xcad
 

SW

New member
I've got it to work. All I needed to do was define a
relation that controlled the generic part, then define parameters could be
changed in each instance. Changing the value of each parameter then changes the
effect of the generic dimension
 

infinidof

New member
The relations for family table instances should occur in the assemblies in which they assembled. Having created the instances and assembling them, use the feature tree to browse to the feature within the instance you wish to relate to the assembly. Right click this feature and then left click on edit within the menu that appears. Use Info>Switch Dimensions from the drop down menu to display the dimension in it's name form. You should see something like: d43:130. The left hand side of the colon is the dimension name within the instance, and will be the same value for the generic and all instances. The right hand side of the colon is the name of the component within the assembly. Create the relation within the assembly, for each instance that is within the assembly, noting that if two instances have just been assembled one after the other, then it is likely that the first will have d43:130 and the second d43:132 (considering the previous example). It is a good idea to doubly regenerate twice when using assembly level relations to drive component dimensions. Note also that after having created these relations, if you were to assemble new components, then reorder any component, then the value within the dimesnioin name on the right hand side will change. Don't worry about this as pro/E updates the relations to the new number. I hope this helps.
 

xcad

Member
mr infinidof
this works fine as you described it


but i have some questions on that


a. these relations refered to this assembly and only this? after 1 year and if we have lost the assembly or moved to another directory, what is it going to happen?


b. every time we want to open the generic part proe opens automatically (in the backround) the assembly in order to solve the equations? if the assembly is big enough? do you believe that is right?






Edited by: xcad
 

infinidof

New member
Hi xcad,


Yeh, if the assy is lost then there'll be a whole world of hurt. Moving is not generally a problem depending on your search.pro file. A pdf of the BOM or TLA drawing will generally help track down lost parts following a major restructure of any network.


I don't think that opening the generic prt will cause the assy to open up. This is a dim and distant memory, but the logic goes thus: The prt dimension driven by the assy relation is saved when the assy is saved. Closing all windows and erasing all not displayed, then opening the prt should result in the prt being opened with the driven dimension value being as it was when the assy was last open. Please check this last one -as I said, it's a distant memory from when I last checked this. As an alternative, only assemble instances of family tables and not the generics. This will give good seperation and will generally save other headaches from occuring.
 

xcad

Member
about the second one...


i haven't try it myself actually but if you open the generic and proe doesn't open (by default) the assembly in order to check and verify the values of the family table instances then we will have NOT made a product that is called "efficient". If additionally proe lets you change the dim values (the same one's that is driven by assembly-relation) the we have a disaster


So i come back on my first opinion that must someone read carefuuly PTC's manuals about its function and NOT to do something that a function is not beendesigned to do.
Edited by: xcad
 

infinidof

New member
continuing on the second one...


So long as one only assembles instances into assys and not generics, then there will be no problem in changing the values of generic dimensions, provided that features within the generic do not fail through inappropriate dimensioning schemes. Hence, effieciency of modelling is maintained. One would not be wise to issue for manufacture any prt that is part of an assy without first opening the assy and verifying the accuracy and intent of all prts in the assy. If one simply wants to reprint a drawing of such a prt, then the value of the driven dimension will be as saved during the previous opening of the assy. Try creating a relation in the assy that drives a prts instance dimension, regenerate the assy,then open the generic of that part, pick Tools>>Family Table and see the modified value of that dimension. Pro/E will also inform you via the information window (message log) that a family table instance value has been overwritten. Further, such dimensions need not even be included in family tables for modification to take place via assy level relations.


Remembering that the original intent of this process was to control prt dimensions with relations in an assy using a dimension within an assy. Once commited to such intent, one would never modify the relation driven dimension of a prt at the prt level. That would be loaded gun stuff. :)


Every pro/E functionality is intent based. That's probably why there are many methods to achieve one goal, but only one or two of these are considered good. Have you looked into skeleton modelling at all? As with all processes, rigid structure or format to the modelling methods must be adhered to. A 3D note in a prt can let future users know how a model works.
 

Sponsor

Top