Relations Between Parts in Different Instances of a Family Table

[ptc-6130662]

Hi all,

New to Creo and I'm at a brick wall.

I created relations between two parts. When I replace part A1 with part A2 my second part, Part B, adjusts as needed.

I created an instance of my assembly in a Family table that contained part A2. When I open this instance Part B does not adjust and I see the warning,

"Some relations are no longer satisfied in ASSEMBLY_A2 for LENGTH:0"

The session ID's are correct in both instances, and the dimensions appear to not drive the length contray to the relations.

In the generic assembly the relations work when I use the replace command, they just don't work when I switch instances in a family table.

I feel like I am missing something fairly obvious but my research into the problem has come up dry.

Any thoughts on what I am missing are very appreciated.

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.

[Dale_Rosema]

John,

Is the surface or face that has a relation with part B found only in Part A1? (i.e. do you just changed the surface by just changing a dimension or are you changing the surface by other features - extrudeds, radii, ....)

If so, the second assemlby cannot find that surface when trying to attached B to part A2.

Thanks, Dale

... and welcome to the forum.

[dgschaefer]

Proe, obviously, treats the "replace" command differently than replacing in a family table. I suspect that it is due to there being two simultaneous instances and proe won't let you drive the same part (B) by two different parts (A1 & A2). Replacing in the assy is more permanent than a family table.

If so, I think you need to create a family table of B with the relevant dimensions in the table. I'm not certain, however, than the relations will just work. You may need a separate line for each instance, with the appropriate session IDs for each.

Then, if you end up with B1 and B2 , the question is does having this all in a family table make sense or is it better to have independent assemblies? Family tables are great for simply things like screws or varying lengths of extrusions, but very quickly get cumbersome as the complexity ramps up. I've been down this road before and they can probably be made to work, but frequently end up being more trouble than they are worth.

There may be other ways of doing this, perhaps elaborating on what you are trying to accomplish (which I assume is more complicated than what you've described here) would help us point you in an alternate direction.

[ptc-6130662]

Thanks Dale and Doug. To clarify I was just changing a dimension in part B that would be driven by Part A, even as part A changed from A1 to A2. So it was pretty simple. The session Id's automatically updated in the relations. What is weird is I defined other dimensions by relations and they updated from part A1 to A2.

I was trying to avoid making a new family table for part B just to keep things tidy, and so I could maybe learn some new tricks.

I found on a non-relations solution that so far seems great. I made the dimension in part B flexible and tied it to the length of Part A. When I change part A to A1 or A2 it automatically updates.

I'll definitely hold to your advice Doug and keep things simple.

If anyone finds a good way to do this with relations let me know.

[dgschaefer]

There's a difference, in my mind, between something like a spring which is a single object that can exist in multiple states and a non-flexible object that has a different definition depending on the assy context. In the former, you don't want multiples as there really is only 1 spring, in the later the object can only exist physically on one state or the other and you'd want separate definitions (models) for each in my mind.

You can do a lot of things virtually that you cannot physically, like drive the dims of one part from another. Though I make use of those tools to improve my designs, I want my virtual database to reflect the realities of the physical database as much as possible. I find that gives me a robust databse.

[Dale_Rosema]

If they are distinct parts, then they should be distinct parts. But if they are truely flexible, then it sounds like you're on the right approach.

If the relationship is still not maintaining, I have added planes that will not change that I can form the relation between the parts.

Thanks, Dale

[ptc-6130662]

Yeah that seems very apparent now. Its not a flexible part and the changes don't carry over to the drawings which makes complete sense.

I think making a family table for Part B is the way to go on this guy.