Programtically delete duplicate parts in assembly

[G60Dubs]

As the title is there any way to step through the presently opened assembly and delete duplicate instances of parts?

[WCrihfield]

Hi @G60Dubs.  If multiple components are found which referencing the same document, then which one should be kept, while all others are deleted?  Are any of them constrained yet?  If the first one is not constrained, but a second or third instance is constrained, but the code only keeps the first instance, and deletes all others, then your constraints will be lost.  Also, are you talking about duplicates per entire structure of all levels of the assembly, or only duplicates per top level, or duplicates per sub assembly?  What I mean is...if a single top level component is referencing Part1, and a single component down within a sub-sub assembly is also referencing Part1, then should that component within the sub-sub assembly be deleted or kept?  What if two different components are both referencing the same model file, but one is set to a different ModelState than the other?  Should the second one encountered, that is set to a different ModelState be deleted or kept?

Edit:  I just attached 2 iLogic rule examples that will both attempt to delete all but the first component found within the entire structure of the assembly that references each unique referenced document, in two different ways.  These examples do not pay attention to any constraints, representation differences, or ModelState differences.  Keep in mind that if a code like is used on a large assembly, it can effect many different referenced documents, so be cautious and only test on files that are not important at first, to be safe.

[G60Dubs]

Hi Wesley

I should have supplied more context to the query - It would be a single level assembly.

My employer has historically used iParts for fasteners and we do not presently use Autodesk Vault as our ADMS although a potential change to Vault Pro has steadily been gathering momentum.

For obvious reasons I have moved us away from continuing to use iParts for fasteners to using authored custom Content so we can use bolted connections, update content without changing the internal GUID  and breaking legacy contraints in assemblies et al.

The ADMS system we presently use does not appear to have the check out all children option which presents a total nightmare when migrating parts and assemblies.  I can check out folders of parts but not a referecned children in assemblies.  As such when i need to migrate the iParts I have added them to a specific assembly - SHCS.iam, Buttonheads.iam, dowels.iam etc.  As there can be hundreds of fasteners per type I add a size group then suppress those and then add the next group.  On a couple of occasions I have added duplicates and have had to start again hence the original question of removing duplicates at a single assembly level.

[WCrihfield]

Hi @G60Dubs.  Did you try to use either of the previous two example codes?  The first example above may have worked OK for a single level assembly, but probably could have used a more efficient process if that information had been available.  I created two more example iLogic rules you can try which are both designed for deleting duplicates in a single level assembly.  Both examples use a List(Of String) to keep track of some aspect of previously encountered component occurrences.  One example gets the FullDocumentName of the Document being referenced by each component.  When a unique FDN (FullDocumentName) is encountered, that occurrence is left alone, and the FDN is added to the list, so we know we have encountered it before, then it iterates to the next occurrence.  If any other occurrence is encountered with the same FDN, the code attempts to delete it.  The other example uses the component occurrence's 'base name' (component name, before the ":" character) as a way to keep track of which ones have been encountered before.  This can be less stable, since component occurrences can be renamed.  The ":" character, followed by an Integer, get automatically added to the ends of our component occurrence names as we add them into any assembly, to keep their names unique.

Both example codes are attached within text files.