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: 

Step through an assembly structure and suppress iParts and content center components.

4 REPLIES 4
Reply
Message 1 of 5
G60Dubs
335 Views, 4 Replies

Step through an assembly structure and suppress iParts and content center components.

G60Dubs
Advocate
Advocate

Hi

 

I've had a look at the forum and see there is sample code of each of the above solutions but not both concurrently.

 

 

Here:

https://forums.autodesk.com/t5/inventor-programming-ilogic/select-ipart-in-assembly-and-change/td-p/...

 

and here:

https://forums.autodesk.com/t5/inventor-programming-ilogic/iterate-through-components-amp-suppress/m...

 

I basically need to step through each assembly leaf and suppress any iPart members and any content center components.  I have a couple of very large assemblies where there are several thousand iParts that I need to suppress in the entire assembly structure to evaluate performance differences.

 

I can hack together basic I logic but this whilst I know will be simple has escaped me.     

0 Likes

Step through an assembly structure and suppress iParts and content center components.

Hi

 

I've had a look at the forum and see there is sample code of each of the above solutions but not both concurrently.

 

 

Here:

https://forums.autodesk.com/t5/inventor-programming-ilogic/select-ipart-in-assembly-and-change/td-p/...

 

and here:

https://forums.autodesk.com/t5/inventor-programming-ilogic/iterate-through-components-amp-suppress/m...

 

I basically need to step through each assembly leaf and suppress any iPart members and any content center components.  I have a couple of very large assemblies where there are several thousand iParts that I need to suppress in the entire assembly structure to evaluate performance differences.

 

I can hack together basic I logic but this whilst I know will be simple has escaped me.     

4 REPLIES 4
Message 2 of 5
WCrihfield
in reply to: G60Dubs

WCrihfield
Mentor
Mentor

Hi @G60Dubs.  You can give this iLogic rule code a try.

 

Sub Main
	Dim oADoc As AssemblyDocument = TryCast(ThisDoc.Document, Inventor.AssemblyDocument)
	If oADoc Is Nothing Then
		Logger.Debug("The iLogic rule named '" & iLogicVb.RuleName & "' exited, because no AssemblyDocument was obtained.")
		Exit Sub
	End If
	Dim oOccs As ComponentOccurrences = oADoc.ComponentDefinition.Occurrences
	RecurseComponents(oOccs, AddressOf ProcessComponent)
	If oADoc.RequiresUpdate Then oADoc.Update2(True)
	'If oADoc.Dirty Then oADoc.Save2(True)
End Sub

Sub RecurseComponents(oComps As ComponentOccurrences, ComponentProcess As Action(Of ComponentOccurrence))
	If oComps Is Nothing OrElse oComps.Count = 0 Then Return
	For Each oComp As ComponentOccurrence In oComps
		ComponentProcess(oComp)
		If oComp.Suppressed = False AndAlso _
			oComp.DefinitionDocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then
			'RecurseComponents(oComp.Definition.Occurrences, ComponentProcess)
			RecurseComponents(oComp.SubOccurrences, ComponentProcess)
		End If
	Next
End Sub

Sub ProcessComponent(oComp As ComponentOccurrence)
	If (oComp Is Nothing) OrElse oComp.Suppressed Then Return
	If (Not TypeOf oComp.Definition Is PartComponentDefinition) Then Return
	Dim bIsCCMember As Boolean = False
	Try : bIsCCMember = oComp.Definition.IsContentMember : Catch : End Try
	If oComp.IsiPartMember Or bIsCCMember Then
		Try : oComp.Suppress(SkipDocumentSave :=True) : Catch : End Try
	End If
End Sub

 

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes

Hi @G60Dubs.  You can give this iLogic rule code a try.

 

Sub Main
	Dim oADoc As AssemblyDocument = TryCast(ThisDoc.Document, Inventor.AssemblyDocument)
	If oADoc Is Nothing Then
		Logger.Debug("The iLogic rule named '" & iLogicVb.RuleName & "' exited, because no AssemblyDocument was obtained.")
		Exit Sub
	End If
	Dim oOccs As ComponentOccurrences = oADoc.ComponentDefinition.Occurrences
	RecurseComponents(oOccs, AddressOf ProcessComponent)
	If oADoc.RequiresUpdate Then oADoc.Update2(True)
	'If oADoc.Dirty Then oADoc.Save2(True)
End Sub

Sub RecurseComponents(oComps As ComponentOccurrences, ComponentProcess As Action(Of ComponentOccurrence))
	If oComps Is Nothing OrElse oComps.Count = 0 Then Return
	For Each oComp As ComponentOccurrence In oComps
		ComponentProcess(oComp)
		If oComp.Suppressed = False AndAlso _
			oComp.DefinitionDocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then
			'RecurseComponents(oComp.Definition.Occurrences, ComponentProcess)
			RecurseComponents(oComp.SubOccurrences, ComponentProcess)
		End If
	Next
End Sub

Sub ProcessComponent(oComp As ComponentOccurrence)
	If (oComp Is Nothing) OrElse oComp.Suppressed Then Return
	If (Not TypeOf oComp.Definition Is PartComponentDefinition) Then Return
	Dim bIsCCMember As Boolean = False
	Try : bIsCCMember = oComp.Definition.IsContentMember : Catch : End Try
	If oComp.IsiPartMember Or bIsCCMember Then
		Try : oComp.Suppress(SkipDocumentSave :=True) : Catch : End Try
	End If
End Sub

 

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 3 of 5
G60Dubs
in reply to: G60Dubs

G60Dubs
Advocate
Advocate

Hi Wesley

 

Thanks for the assistance.   This works great at the top level but does not recurse into subassemblies.

 

 

 

0 Likes

Hi Wesley

 

Thanks for the assistance.   This works great at the top level but does not recurse into subassemblies.

 

 

 

Message 4 of 5
WCrihfield
in reply to: G60Dubs

WCrihfield
Mentor
Mentor

Hi @G60Dubs.  One small change you can try would be to switch which line of code is commented vs uncommented, between Lines 19 & 20.  They both work very similarly in many scenarios, but both can also cause different results in some scenarios.  It has to do with context.  Line 20 is maintaining 'lineage' from the main assembly, while Line 19 breaks that lineage every time it steps into a different ComponentDefinition, where it is effectively editing other documents internally, instead of just assembly level settings from the perspective of the main assembly.  I was not 100% sure about your exact intent with this process.

 

Also, keep in mind that it is the job of the ModelStates to record suppression status changes.  And there is at least one ModelState in every model document, unless it is something like a Content Center member, iPart/iAssembly member.  So, suppression was intended to be recorded at each level, by the ModelState in that model file, then when you place that model into an assembly, as an assembly component, you should set the ModelState of that assembly component to one of the ModelStates that exists within that the model file that the component references.  Then that component's ModelState setting is recorded by the ModelState that was active in the assembly at the time you placed that assembly component directly into.  Then when you place that assembly into another assembly, as an assembly component, you would that component to one of the ModelStates that is available within the model file it is referencing, and so on.  This process was meant to be set-up from the bottom level, up to the next level, then up to the next level, and so on, not from the top level, then working its way down.  A ModelState in an assembly can only keep track of the components that are directly placed with it, and not any of the sub components.  Those sub components are managed by the ModelStates within the sub assemblies.

 

Also, when there are two or more assembly components within the entire structure of the assembly that reference the same file on disk, but different ModelState version of it, then the first instance the code encounters may act normally (Read/Write), but the next instance it encounters will most likely act like (ReadOnly), so nothing will happen to it.  We are supposed to be able to update the main assembly between working on the first instance and working on the second instance, to make the second instance become Read/Write again, but that is not always convenient or efficient when working on a huge assembly.

Below is a link to an online help article which points this issue out.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=GUID-418B956A-AC3F-48D8-BEBC-FC28C4B51DA2 

 

My guess is that you would have to create one or two special ModelStates within each sub assembly that contains any iPart members or content center members, in which those types of components are suppressed.  Then set the component representing those sub assemblies to one of those special ModelStates at each level of the overall assembly structure, instead of trying to control all suppression at all levels of the whole assembly at one time, without using the ModelStates along the way.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Hi @G60Dubs.  One small change you can try would be to switch which line of code is commented vs uncommented, between Lines 19 & 20.  They both work very similarly in many scenarios, but both can also cause different results in some scenarios.  It has to do with context.  Line 20 is maintaining 'lineage' from the main assembly, while Line 19 breaks that lineage every time it steps into a different ComponentDefinition, where it is effectively editing other documents internally, instead of just assembly level settings from the perspective of the main assembly.  I was not 100% sure about your exact intent with this process.

 

Also, keep in mind that it is the job of the ModelStates to record suppression status changes.  And there is at least one ModelState in every model document, unless it is something like a Content Center member, iPart/iAssembly member.  So, suppression was intended to be recorded at each level, by the ModelState in that model file, then when you place that model into an assembly, as an assembly component, you should set the ModelState of that assembly component to one of the ModelStates that exists within that the model file that the component references.  Then that component's ModelState setting is recorded by the ModelState that was active in the assembly at the time you placed that assembly component directly into.  Then when you place that assembly into another assembly, as an assembly component, you would that component to one of the ModelStates that is available within the model file it is referencing, and so on.  This process was meant to be set-up from the bottom level, up to the next level, then up to the next level, and so on, not from the top level, then working its way down.  A ModelState in an assembly can only keep track of the components that are directly placed with it, and not any of the sub components.  Those sub components are managed by the ModelStates within the sub assemblies.

 

Also, when there are two or more assembly components within the entire structure of the assembly that reference the same file on disk, but different ModelState version of it, then the first instance the code encounters may act normally (Read/Write), but the next instance it encounters will most likely act like (ReadOnly), so nothing will happen to it.  We are supposed to be able to update the main assembly between working on the first instance and working on the second instance, to make the second instance become Read/Write again, but that is not always convenient or efficient when working on a huge assembly.

Below is a link to an online help article which points this issue out.

https://help.autodesk.com/view/INVNTOR/2024/ENU/?guid=GUID-418B956A-AC3F-48D8-BEBC-FC28C4B51DA2 

 

My guess is that you would have to create one or two special ModelStates within each sub assembly that contains any iPart members or content center members, in which those types of components are suppressed.  Then set the component representing those sub assemblies to one of those special ModelStates at each level of the overall assembly structure, instead of trying to control all suppression at all levels of the whole assembly at one time, without using the ModelStates along the way.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 5 of 5
G60Dubs
in reply to: G60Dubs

G60Dubs
Advocate
Advocate

Morning Wesley

 Aplologies for the delay in reply.  Many thanks for your detailled exaplanation which will prove useful to many.   I've been working for my present employer for about 19 months and have a lot of improvements just about to be pushed through.  Historically I am used to supressing or shrinkwrap subsituting for the next level up in large assemblies in order to manage usability of large to level assemblies.  This specific request was borne from the need to highlight to management how some simple changes in workflow can bring significant timesaving/productivity improvements and the best example I had to draw on was existing top level assemblies where there was 35,000ish instances of unmigrated components with a large number of these being iPart fasteners.  Unsurprsingly, the load times were excessive as were the update times and once loaded the top level was unworkable.   Hence, I needed a quick and dirty method to suppress iParts.  As expected the example had its' intended effect on my peers and also management - The example top level assembly load time dropped from 25 minutes to around a minute and resulted in it also being workable given me approval to push through a switch from legacy iPart fasteners to custom authored content and other workflow improvments.  A definite win win on this occasion. 

0 Likes

Morning Wesley

 Aplologies for the delay in reply.  Many thanks for your detailled exaplanation which will prove useful to many.   I've been working for my present employer for about 19 months and have a lot of improvements just about to be pushed through.  Historically I am used to supressing or shrinkwrap subsituting for the next level up in large assemblies in order to manage usability of large to level assemblies.  This specific request was borne from the need to highlight to management how some simple changes in workflow can bring significant timesaving/productivity improvements and the best example I had to draw on was existing top level assemblies where there was 35,000ish instances of unmigrated components with a large number of these being iPart fasteners.  Unsurprsingly, the load times were excessive as were the update times and once loaded the top level was unworkable.   Hence, I needed a quick and dirty method to suppress iParts.  As expected the example had its' intended effect on my peers and also management - The example top level assembly load time dropped from 25 minutes to around a minute and resulted in it also being workable given me approval to push through a switch from legacy iPart fasteners to custom authored content and other workflow improvments.  A definite win win on this occasion. 

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

Post to forums  

Autodesk Design & Make Report