Starting in December, we will archive content from the community that is 10 years and older. This FAQ provides more information.
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:
and here:
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.
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
(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
(Not an Autodesk Employee)
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.