Difference between ComponentOccurrence and ComponentOccurenceProxy?

Difference between ComponentOccurrence and ComponentOccurenceProxy?

amitabhVA4SD
Advocate Advocate
2,604 Views
9 Replies
Message 1 of 10

Difference between ComponentOccurrence and ComponentOccurenceProxy?

amitabhVA4SD
Advocate
Advocate

Hello,

 

What is the difference between ComponentOccurrence and ComponentOccurenceProxy w.r.t to traversing the Inventor assembly?

Each instance of a part in an assembly is a component occurrence that has the native object as the part from which the instance has been created and positioned in the assembly. Is the concept of ComponentOccurenceProxy only applicable when we have sub-assemblies within an assembly document?
I have been using SurfaceBodyProxy, FaceProxy, and EdgeProxy and these API interfaces are clear to me.

Can someone explain the ComponentOccurenceProxy Interface usage in detail?

 

I am attaching a sample Inventor Tree schema that might be helpful.

My current understanding:

Assem0 is a component and all the Child Parts are Component Occurrences

Assem1 --> Sub-Assemblies Assem2:1, Assem2:2 and Assem3:1 are ComponentOccurenceProxy

Assem2  document when opened alone - All the child parts are ComponentOccurence

amitabhVA4SD_0-1631567526127.png

 

If I have an assembly and I want to query the unique edges and faces of every single instance part, should I get the SurfaceBodyProxy, FaceProxy, and EdgeProxy info from ComponentOccurence or ComponentOccurenceProxy?

 

Thanks,

Amitabh Mukherjee

0 Likes
Accepted solutions (1)
2,605 Views
9 Replies
Replies (9)
Message 2 of 10

amitabhVA4SD
Advocate
Advocate
0 Likes
Message 3 of 10

CattabianiI
Collaborator
Collaborator

It's a fondamental concept for non trivial programs and it is well documented between blogs, forum and documentation.

Here's some useful link:
Proxies in manual: 


Note: The idea of proxies can be extended to cover the ComponentOccurrence object (the concept is very similar). Consider nested assemblies, or subassemblies, where the level of nesting is three or more levels. An occurrence can be an instance of an assembly definition, not just a part definition. At the top level (the instance), this occurrence is a ComponentOccurrence object as expected, but at other levels these occurrences are represented by ComponentOccurrenceProxy objects.


 

Attributes of ComponentOccurrence vs ComponentOccurrenceProxy in AdnDevBlog:

 
CattabianiI_3-1631711820295.png

 

And to answer the question about refkey look at: ComponentOccurrence contexts and Reference keys:

The same applies to all other ComponentOccurrence properties including GetReferenceKey(). If you get a reference key for the Part1 occurrence in SubAsm1's context, it provides a key that is suitable to identify Part1 inside SubAsm1. This is not the same key that you get for SubAsm1:1->Part1 in Asm1, which obviously needs to be different from SubAsm1:2->Part1 as well, since this is for identifying a given instance of Part1 in Asm1 and not only in SubAsm1.

 

Message 4 of 10

Z0methink
Enthusiast
Enthusiast

ComponentOccurrence allows you to work with an assembly document only. ComponentOccurenceProxy allows you to work with a part in an assembly without opening it separately.

0 Likes
Message 5 of 10

amitabhVA4SD
Advocate
Advocate

@Z0methink - Isn't NativeObject property provided to give that information. A proxy should be always in Assembly Context. Can you please elaborate on your findings?

0 Likes
Message 6 of 10

Z0methink
Enthusiast
Enthusiast

Here's a medical example for you: ComponentOccurrence is therapy and ComponentOccurrenceProxy is surgery for assembly.

0 Likes
Message 7 of 10

Z0methink
Enthusiast
Enthusiast

ComponentOccurrenceProxy is black magic, voodoo. It creates a proxy-object, sticks commands into it and this changes the object.

0 Likes
Message 8 of 10

BrianEkins
Mentor
Mentor
Accepted solution

If you understand how proxies work in the case of part geometry, then the idea of proxies for occurrences shouldn't be too hard to learn.

 

First, a proxy isn't black magic, and nothing new is created when you get a proxy. A proxy is a reference to an object that exists outside the top-level component, and the proxy defines the full path from the top-level down to the object. The path is made up of a list of occurrences, and the final item in the path is the object itself.  I like your original example picture, which I've copied below.

 

First, let's look at Assem0.  The four occurrences in it are not proxies since they exist in Assem0.  But let's look at a face that is in PartA. Because PartA is referenced twice: PartA:1 and PartA:2, that face is displayed twice in Assem0, even though it really only exists once in PartA. Each of the faces is represented in the assembly by a FaceProxy. The path of the first proxy is PartA:1/Face, and the other is PartA:2/Face.  Because the proxy has this path, it knows how the object is positioned in the assembly. Thus, when you query for information (i.e., normals) from the face, it can provide that information as if the face exists in the assembly.

 

With Assem1, the occurrences Assem2:1, Assem2:2, Assem3:1 are regular occurrences because they exist in Assem1. However, the occurrences for PartE, PartF, PartM, and PartN are all ComponentOccurrenceProxy objects because they don't exist in Assem1 but are referenced through the top-level occurrences.  This is precisely the same idea as the face proxies. For example, PartE is seen four times in Assem1, so a face in PartE will be seen four times.  In this case, the paths to these faces are:

  • Assem2:1/PartE:1/Face
  • Assem2:1/PartE:2/Face
  • Assem2:2/PartE:1/Face
  • Assem2:2/PartE:2/Face

If you open Assem2 directly, then PartE:1, PartE:2, and PartF:1 are not proxies since they exist directly in Assem2.  Hopefully, this helps and doesn't just add to the confusion.

 

Example.png

 

 

---------------------------------------------------------------
Brian Ekins
Inventor and Fusion 360 API Expert
Website/Blog: https://EkinsSolutions.com
Message 9 of 10

amitabhVA4SD
Advocate
Advocate

Thank you @BrianEkins.

Your explanation is very clear and easy to understand.

0 Likes
Message 10 of 10

infoQ82EV
Contributor
Contributor

@BrianEkins I would have a question to your example because I am confronted with this at the moment:

Lets say we found Part1 and the face we are searching for is in its First ExtrudeFeature we maybe got by name property. That Face would be known to be the StartFace and First of the returned collection of this. But because this is the first feature of this Part, there would naturally made some more features in this which modifyed this face. Reading the reference in documentation, that would mean in my understanding, if I now query this first feature for this particular face, there would be no return value(FaceObject) because it has been modified.

But how would I now be able to find this again? I was thinking about Attributes via your nifty attribute helper, but in case of mentioned modifications, the attribute would point to nothing from this. Thinking about referenceKey usage would require to get this face from first feature, but like understood that would be nothing...

I did nowhere find an explanation to that only that facts from different adn blogs... I was also thinking about alternativly using reference keys pointing in asm context to this face but since i am also working with deleting that component occurences and re adding them, that would also destroy that...

0 Likes