Community
Inventor Programming - iLogic, Macros, AddIns & Apprentice
Inventor iLogic, Macros, AddIns & Apprentice Forum. Share your knowledge, ask questions, and explore popular Inventor topics related to programming, creating add-ins, macros, working with the API or creating iLogic tools.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

VBA insert failing on a surface edge

5 REPLIES 5
SOLVED
Reply
Message 1 of 6
benny.deswert
271 Views, 5 Replies

VBA insert failing on a surface edge

Hi all

I have this macro I have been using for a long time wich basicly gets a model from the content center and constraints it to a pipe using an insert.

A new model was added to CC and I want to include it in my macro. They added revolved surface ring in the center of the part for easy constraining.  which looks like this and is a surface in the model tree

 

bennydeswert_0-1693491436036.png

bennydeswert_1-1693491489929.png

 

The problem is the insert I have been using fails with this edge.

The old line to get the edge looks like this: Set oEdge3 = occ.SurfaceBodies.Item(2).Edges.Item(1)

The new line looks like this: Set oEdge3 = occ.Definition.Document.ComponentDefinition.WorkSurfaces.Item(1).SurfaceBodies.Item(1).Edges.Item(1)

It returns as being a "5124 kcirclecurve". 

Because the surface isnt in the "occ.surfacebodies" with the solids as I would expect and found in other examples.

 

If I get the edges parents name I get "JT Constrain Surface" as in the screenshot.

So I am fairly sure I have the correct edge.

 

The line for the insert wich has always worked is this one: Set oInsert = oAsmCompDef.Constraints.AddInsertConstraint(oedge, oEdge3, True, edgedist)

 

Now I created a small macro wich allows me to manually select the 2 edges, and then places a constrain in exact the same way. This works.

 

So what am I missing here. Am I trying to select the edge in the wrong place? But it's the only place in the models structure where I can find the "JT constrain surface".

 

Thank you.

5 REPLIES 5
Message 2 of 6
WCrihfield
in reply to: benny.deswert

Hi @benny.deswert.  I do not know what type of object your 'occ' variable represents, but that is usually used for a ComponentOccurrence type object.  If that is the case, then it looks like you are getting these pieces of geometry from within components.  If that is the case, then the object you get back will not be in the same 'context' as the main assembly.  Context means the 3D coordinate space.  The edge you are getting is in the context of the component, not the main assembly, so you will need to get the 'proxy' of that edge (EdgeProxy), then use that EdgeProxy for your constraint.  To get the proxy, use the occ variable's CreateGeometryProxy method, by inputting the original Edge object as the first input object, then input a variable for an EdgeProxy object, that you just created before that line, and have not set a value to yet.  That method will set the variable's value to the proxy object that is in the context of that components parent assembly.

Edit:  Oh, and by the way occ.Definition is the same as occ.Definition.Document.ComponentDefinition. 

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 3 of 6
benny.deswert
in reply to: WCrihfield

Hi @WCrihfield 

 

Thank you for your reply.

Indeed it's geometry from a part in an assembly.

I understand what you mean with the proxy.

However I don't understand why you need the proxy for the surface edge, and not for an edge on a solid of the same part. The macro and insert work just fine if I do it on a different edge of a solid.

Can you elaborate on that please?

 

Thank you.

Message 4 of 6

Hi

I got it working easily with the proxy, thank you.
But I still don't understand why the other edges worked without a proxy, or when a proxy is needed.

Grts
Message 5 of 6
WCrihfield
in reply to: benny.deswert

Hi @benny.deswert.  The subject of proxy objects has always been complicated to understand, and complicated to try to explain to someone else, even if you do understand it pretty well yourself.  I have attempted to explain them to other folks several times before within multiple responses here on this forum also.  Proxies basically just a virtual copy of geometry from another 'context', and placed into the 'context' of the assembly, then positioned and oriented the way you want it to be.  That proxy geometry is a completely different object than the original geometry, which still remains within its original context.  And proxy objects exist on a per level basis also.  So, if you have an assembly that has a sub assembly in it, and that sub assembly has sub assemblies in it, and so on, the components within those lowest level sub assemblies that represent parts, will have a proxy of its geometry within that lowest level sub assembly, and will also have proxy geometry within every level sub assembly including the top level assembly.  The proxy within a sub assembly is not the same object as the proxy in the higher or lower level assembly.  They proxies in upper levels are copies of copies (or proxies of proxies).  The real (not proxy) geometry will only exist within the PartComponentDefinition that the lowest level component is referencing.  The higher level proxy objects reference the lower level proxies (or original geometry), but the lower level proxies (or original geometry) does not reference (or know about the existence of) the higher level proxies.

 

If you use the 'ThisApplication.CommandManager.Pick() function to select geometry from the context of the main assembly, everything you manually pick that way will return an object that is already in the context of the main assembly, because that is the nature of that functionality.  If you picked an entire component, just a face, or edge,  then all that type of stuff is associated with a component that was inserted into the assembly, and it will already be a top level proxy of the geometry.  But when accessing those pieces of geometry by code (without using the Pick method), you may get a proxy or original geometry, depending on how or where you get it.  Any time you go within the 'definition' of an assembly component or referenced document to find the object, you are then outside of the context of the main assembly, and within the context of that other document, so anything you get a reference to, will not be immediately usable within the main assembly.  You will need to find the proxy copy of that object that is within the context of the main assembly before you will be able to measure or constrain between it and anything else that is within the context of the main assembly.  And if that object, lets say a Face type object, for example, belongs to a Part that is being referenced by a third level component (a component within a sub assembly), then you will first need to find the proxy of that Face (a FaceProxy) that is within the context of that sub assembly (same context as the component).  Then you will need to find the proxy of that FaceProxy that is within the context of the (next level up or parent level), which in this case would be the main assembly.  Then that top level object's Type is still FaceProxy, but it is a FaceProxy of the FaceProxy in the sub assembly, which was a proxy of the component within it, then within the 'definition' of that component (a PartComponentDefinition) is the 'real' or original regular Face object.  Each 'context' is the 3D coordinate system of another document that the geometry was copied into, and that copied geometry could potentially be positioned and oriented differently within each context (in relation to the origin planes of each coordinate system).  For example, if you have two parts open on two different tabs, you can not start the measure tool in one part, click a face within that part, then switch to the other tab, for the other part, then click on a face on that part and expect a distance or angle measurement.  Because each one does not know about the other, and they are within different coordinate systems.

 

The primary method for finding, and getting a reference to the proxy geometry object that is within context of an assembly component's parent assembly, is to use the CreateGeometryProxy method of the assembly component that you got this level's geometry from.  What I mean by 'this level's geometry' is, it may be real/original geometry, from a part that the component directly references, or proxy geometry from a lower level component that this component references.  Even though the method starts with 'Create', as far as I can tell, it does not actually create anything, it just returns a reference to the already existing object that is within the parent level context.  Because if there was no parent level, the method would fail.

Whew...I hope that helps some. 😅

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 6 of 6
benny.deswert
in reply to: WCrihfield

Sorry late reply.

It does help, Thx!

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Technology Administrators


Autodesk Design & Make Report