IsAssociativeToDesignViewRepresentation always returns False beyond first level

IsAssociativeToDesignViewRepresentation always returns False beyond first level

DRoam
Mentor Mentor
399 Views
3 Replies
Message 1 of 4

IsAssociativeToDesignViewRepresentation always returns False beyond first level

DRoam
Mentor
Mentor

I'm trying to iterate through my assembly hierarchy and determine which sub-assemblies aren't set associative to a View Rep. The first level of sub-assemblies works fine. However, the second level and beyond always returns "False" for "IsAssociativeToDesignViewRepresentation", even if the occurrence actually IS associatively set to a View Rep under the current active View Rep.

 

I attached a sample assembly that demonstrates the issue. If you run the "Check Associative Statuses" local iLogic rule, it'll say that the "SECOND LEVEL" assemblies are non-associative. But if you check manually, you'll see that's incorrect.

 

What's going on here? How can I determine the "associative" status for each occurrence at each level in my Top Assembly (for my Top Assembly's current active View Rep)?

 

Files are in Inventor 2017 format.

0 Likes
400 Views
3 Replies
Replies (3)
Message 2 of 4

JamieVJohnson2
Collaborator
Collaborator

DRoam, don't use .SubOccurrences.  Sounds strange right.  Think about it.  Inventor does not have the option for the second tier of the base level to associate to the base level, but the first tier has the second tier associated to the first tier (as if the first tier was the base level).

 

SubOccurrences keeps the tree intact.  You don't want the full tree, you want to start a new shelf from each tier, so use ComponentDefinition.Occurrences for each recursive value.

 

Jamie Johnson : Owner / Sisu Lissom, LLC https://sisulissom.com/
0 Likes
Message 3 of 4

DRoam
Mentor
Mentor

I get what you're saying about SubOccurrences -- I'm getting the view rep state as it's defined for the sub-occurrence at the top assembly level, which is "none at all".

 

However, ComponentDefinition.Occurrences doesn't seem to work either. I think because now I'm checking the view rep states as they're defined in the current state of the occurrence's DOCUMENT. When I replace "oOcc.SubOccurrences" with "oOcc.Definition.Occurrences", I now get the IsAssociative status as it is in the current active view rep of the file itself. Not as it is in the view rep that's associatively set in my Top Assembly.

 

Hope that makes sense...

0 Likes
Message 4 of 4

JamieVJohnson2
Collaborator
Collaborator

So, I looked deeper to see if I can clue into you.  But I can't, so I will attempt to show you what I learned.  Perhaps its a limit of Inventor, but I don't think it is a design flaw.  Inventor Design View Representation only tracks immediate child level links (aka SubOccurrences are ignored).  Active Edit Document does not change Active Document, so nothing is recalculated based on Active Edit Document.  Change the Active document resets the top level to another file so its 'first level' children are being calculated against.  Not a design flaw, for the functionality to work a 'link' only needs to know what the child wants.  The Child should know what its children want, because the link is a one configuration path to be followed.  All other paths, break Associative (such as grandchild displaying differently to grandpa rather than papa).

4 images attached.Top Assy to First Tier - AssocTop Assy to First Tier - AssocTop Assy to Second Tier - BlockedTop Assy to Second Tier - BlockedEdit First Tier to Second Tier - BlockedEdit First Tier to Second Tier - BlockedOpen First Tier to Second Tier - AssocOpen First Tier to Second Tier - Assoc

Jamie Johnson : Owner / Sisu Lissom, LLC https://sisulissom.com/
0 Likes