Another relation question

[John.Pryal]

Hi all,

i have been trying to figure out if it is possible to have a local parameter equal an external parameter in a family table instance. Let me elaborate, i have a generic part with one instance, with a local parameter a1, i have added this parameter to my family table, in the generic a1=0 & in the instance a1=0.2 . I have discovered that you can only add parameters created within the generic part to the family table (local) to create a variant. Now i have a second part, with no features, (except for a default cs) only parameters. One of these parameters b1, has the same value as a1 in the instance, 0.2 . I have assembled all 3 parts together, to enable me to pass information via relations from one part to another. I have written a relation stating that a1 (in the instance) = b1, but what i am finding is that the generic a1 parameter instead of remaining 0, is also made 0.2 . I want to be able to modify the value of a1 by modifying b1 in the second parameter only part. Can this be achieved?

Best Regards

John

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[John.Pryal]

Hi all,

at this moment in time i see that 55 of you have viewed this post, but no replies. Reading back my post i realize that it was a bit chapter & verse, & that it was confusing to some. This is a problem i really need to find a solution to, so i will attempt to simplify the question. Is it possible to control a family table variant with a realtion, rather than enter a value for it?

Best Regards

John

[nonamepicked]

Hi,

to answer your question(s):

You can control instances of family tables with relations. It depends on the value: a simple dimension can be controlled via relations by IF ... COND...END IF.

E.g.

IF PARAM1==1

A1=0.2

A2=...

A3=...

END IF

The parameter PARAM1 is a value in your family table.

To control features please look at the help center: Pro/Program - there you can control if a feature is suppressed or not

But it's not possible to have dimension1 in part1 = dimension2 in part2.

Therefor you need AAX. One possibility is to control an assembly with both parts. You enter the desired value in your asm and it's transfered to both parts.

You can also control a whole assembly via skeleton and layout.

It's not so easy to explain the whole procedere.

Help center: AAX; Layout; Pro/Program

Hopefully it helps.

[John.Pryal]

Hi,

i spent an hour trying to make this work, but to no avail. Everything looks ok until you change the driving parameter, then i get "lost symbol" messages in the relation.

My search for a solution continues. I should add that i am trying to achieve this with standard pro-e functionality, no advanced licence options.

Regards

John

[VladimirPalffy]

Hello.
I created a short video, where you can see how to link the parameters from several models.

I repair a video link and I have added video :o)

[John.Pryal]

Thank you both for your replies. Firstly, i asked if an instance could be controlled by a relation, but can that relation contain a parameter from a completely separate part? Secondly, Vladimir, i watched your video, i am not quite sure what you were attempting to show me. It looked like you had a parameter created locally within your generic part, that parameter was then added as a family table column. I'm not sure how that helps me, did your video play out as you intended? i did not see anything after the instance was opened, what was the relevance of the third part?

Thank you both

John

[VladimirPalffy]

Hello John
If I know, the instance model it is not possible controlled with ralations.

If you need link to parameters from other models it is possible only in assembly mode - see the video 🐵
(Video shows how you can use parameters in the family table and then you use at the assembly, which manages the third model parameter.)

Vladimir

[John.Pryal]

Thank you Vladimir,

i think that you have confirmed what i feared, that the instance variant cannot be controlled in the way i need. I actually want to do the reverse of what you have described in detail, i want to manage the instance with a parameter created in the third model.

Thank you for your help

Regards

John

[nonamepicked]

Hi,

maybe you can control one model (instance) with the inheritance feature and/or the external copy geom of Pro/E AAX.

Example:

There is an extrusion between two planes in part 1

- you can inherit this feature to part 2 (also as material cut, so part 1 = shaft and part 2 = bearing).

OR

- Insert -> Shared Data -> Copy Geometry

- select both planes as references

- create a new feature in part 2 between both planes

(maybe this links works also on your computer:

inherit: http://localhost:61317/asm/asm_three_sub/To_Create_an_Inheritance_Feature.html#To_Create_an_Inheritance_Feature_ToCreateAnInheritanceFe609_33

copygeom: http://localhost:61317/asm/asm_three_sub/To_Create_a_Copy_Geometry_Feature.html#To_Create_a_Copy_Geometry_Feature_ToCreateACopyGeometryF637_22 )

That's the only way I know (at the moment) to control part 2 with part 1.

[John.Pryal]

Once again, i thank you for your reply, but i need to solve this using standard pro-e functionality.

regards

John

[Kevin]

If I understand what you want to do correctly you can do it. For this first method I believe you need the advanced assembly license. The second method you should be able to use.

1) You create a layout that has a parameter (ie LENGTH) that will control the desired dimension in each part, declare the layout to both parts, and write relations for the parts that set the part dimension equal to the layout parameter. For the family table part add a YES/NO parameter (ie EXTERNAL) to the generic and add it and the dimension value to the table. In the generic the relation will have the form:

IF EXTERNAL == YES

d18=LENGTH

ENDIF

For instances with EXTERNAL set to YES the relation will control the dimension value and for those with EXTERNAL set to NO you can type a desired value.

2) Create a dummy assembly (you will need to keep the assembly) that you need to maintain the value (needed to control the value in one place). Create an assembly parameter to pass the down to a parameter in each of the parts. At the part level use the YES/NO parameter and relations mentioned above.

[DavidButz]

John,

I'm going to take a quick stab at this, hoping that I understand your desire for both functionality and simplicity. In the generic of the dependent family table part create a set of parameters for the values you wish to appear in the table for the values of "a1" in the various instances, e.g. a1_1, a1_2, a1_3 for instances 1, 2, 3, etc. Put those parameter values in the family table, then set a relation to drive the relevant parameter instead of the dimension, e.g. a1_2=b1. Could this work for you?

David

[DavidButz]

My mistake; I thought that woudl work, but it isn't allowed.

[John.Pryal]

Thank you everyone for the replies,

i have given up hope of trying to solve this conundrum. The problem is the family table & the way it works, i believe it is not possible to control a parameter in the family table with an external parameter. Kevin, your approach may work, but i was trying to do this with standard pro-e licences, i do not have advanced assembly licence. I did adopt a very similar approach, i have the assembly, & tried to pass down to each part, but each time the parts regenerate, i see a message that the family table overrides the relation, or words to that effect. For now i will abandon this, if anyone has any more ideas, please let me know.

Best Regards

John

[Kevin]

Did you try the second approach I gave? The first one does require advanced assembly but I don't think the second one requires it. I'll give the steps again in a little more detail so you can determine if I'm understanding the problem correctly. My understanding is you want to control a parameter a1 in a model that is going to have a family table by setting it to a parameter value b1 that is in another model. However you only want to set a1=b1 for one of the instances and you want to be able to change a1 for the other instances. The steps for approach 2 that I gave would be:

1) Create a dummy assembly that contains the generic of the family table controlled part and the part that contains the parameter b1. You need to maintain this assembly to pass the value of b1.

2) In the generic you should have A1 and B1 in the parameter list. Write a relation in the dummy assembly that sets b1 of the generic to b1 of the other part. It will have the form B1:0=B1:2 where B1:0 is the parameter in the generic B1:2 is the parameter in the part you are trying to pass to the generic.

3) Write a relation in the generic A1=B1. This will set a1=b1 for all instances. This isn't what you want so you need to modify the relation. A YES/NO parameter can be used to control whether the relation is applied.

4) Create a YES/NO parameter ( ie EXTERNAL) to control whether a1 is externally controlled (in other words you are going to control the parameter by a relation).

5) Edit your relation in the generic to be:

IF EXTERNAL == YES

A1=B1

ENDIF

6) In the family table add the parameters EXTERNAL and A1. For the instances you want to control externally (by the relation above) set the value of EXTERNAL to YES and set the value for the other instances set to NO. For those instances that EXTERNAL is set to YES you won't be able to change the value of a1 because the relation overrides manual input. For those instances that EXTERNAL is set to NO you can change the value of a1 to what you want it to be since it is not controlled by the relation.

If this is not what you are tying to do then I'm not understanding the problem based on the way it's written.

[John.Pryal]

Hi Kevin,

ok, i think i have cracked this. I read through your post, & was just about to give it a go, when something occurred to me. Does the location of the relation matter? i have been writing the relation at part level, via my assembly. I already have the dummy assembly you speak of, only it is a legitimate assembly, it contains my generic part, my instance & the third part with the driving parameters. I wrote the very simple parameter a1=b1 & it does exactly what i want it to do, a1 on my generic remains 0, while a1 on my instance becomes 0.2 & is driven by b1 which = 0.2 also on the third part. If i modify b1 to say 0.3, then a1 on the generic again remains 0, while a1 on the instance becomes 0.3. So, it would appear that location was the key here. Perhaps your approach would work too, but this appears to work & is much simpler, but you did sow the idea in my head & for that i am very grateful. Thank you ever so much for your time & effort. I need to test this some more, but things look good.

Best Regards

John

[Kevin]

Depending on what you're after it can. The approach you are using sets a value for a1 and makes a change to the family table based on the relation in the assembly. This would be the same as opening the generic and manually making a change to the table if not using the assembly relation.

The logic for what I did was you wanted to pass a parameter b1 to a part that has a family table, write a relation at the part level that would allow you to set the value of a parameter a1 manually in the instances or control one or more instances with the relation a1=b1. You need a table column for a1 to enter its value. The thing to remember is part instances are not actual PRT files in your directory. The instances get their geometry, parameters, and relations from the generic part so you want to pass the b1 parameter value to the generic and write the relation a1=b1 in the generic. If you generate the table at this point a1 will equal b1 for all instances. If you want the relation to apply for only a certain instance(s) you need set the condition for when the relation is applied in the generic. This is the reason for the YES/NO parameter EXTERNAL. The EXTERNAL parameter also needs to be added to the table so you can select (change to YES or NO) which instances the relation controls. You could also set the relation to look by the instance name instead of using a YES/NO parameter. Having multiple b values passed to the generic would some more complexity.