What's new
By:

"Save as" menu doesn't work properly with large assemblies in V29 (29060)

F

Finish

Member
Hi there,
just noticed in the new V29 (29060) that the sorting function in the“ Save As” menu doesn't work anymore for the first column assemblies/parts as it does for the others (file name or location).
In V28 this worked and was quite handy for some of my usecases with large assemblies.

Looking forward to a fix.
 
Last edited:
Wow, this is more buggy than I initially thought.

I often work with large customer assemblies containing hundreds of parts, and I need to rename them because of extended file name length limitations so I can continue working with the assemblies afterward.
For this, I use an AutoHotkey script that renames the parts sequentially (12001, 12002, etc.). With the new “Save As” menu, this still mostly works, but it creates several issues that I cannot fix manually because V29 seems to generate additional files and “ghost” duplicates in the table.

Please check the attached pictures.
In “Duplicates 1”, the table reports duplicates for 12469, 12490, and 12600, but these entries are not visible anywhere in the table, even after sorting by file name and refreshing the list.
You can also see that file 12555 appears twice, but only one of them is marked with the red duplicate symbol.

In “Duplicates 2”, I only renamed one of the two 12555 entries manually to 12601 to fix this dublication.
For some reason, this creates two files named 12601, while the remaining 12555 is still marked as having a duplicate, even though the corresponding duplicate is not visible in the list.

So I can't get rid of those dublication errors at all at the moment to save the renamed assembly.

It would be great if this could be fixed in a future update. At the moment, it seems I will have to return to V28 to stay productive.
 

Attachments

  • Dublicates.jpg
    Dublicates.jpg
    60.3 KB · Views: 22
  • Dublicates 2.jpg
    Dublicates 2.jpg
    90.2 KB · Views: 22
Did some additional testing.

I can confirm that this has nothing to do with my script usage — this appears to be an issue with the “Save As” menu in V29 itself.
I imported a small STEP file with 8 parts, and renaming parts worked correctly. However, with a STEP assembly containing 500+ parts, the same issues occur even when I rename files manually.
When I manually rename a single part, I repeatedly end up with two entries using the same number.

So either:
  • a second ghost entry with the identical file name is being created, or
  • another existing file in the list is incorrectly being renamed to the same name.
What’s strange is that these entries are not always marked as duplicates, even though they clearly have identical file names.

Unfortunately, I can’t share those STEP files for testing because the customer data is confidential.
 
Last edited:
Can you confirm the files are going to the same folder? Alibre only calls them duplicates if they will save to the same folder at the same time.
 
NateLiquidGravity said:
Can you confirm the files are going to the same folder? Alibre only calls them duplicates if they will save to the same folder at the same time.
Click to expand...
The duplicates are going to the same folder, it's impossible to know for the ghost ones that don't appear in the list, even after a refresh.
Some files I rename it weirdly changes the folder to a random one sometimes, usually a folder something else in the assembly is saved in.
 
I have found the issue for me seems to be in assembly's with multiple sub-assembly's in them, if I go into the sub-assembly and save it as the new version it seems to work ok, I just then have to go into the main one and replace the sub-assembly's with the new ones.
 
I’m working with STEP turning Rhino/Grasshopper projects into PDM libraries. There are issues with STEP assembly part naming and component recognition. One example, if prt1000 is used 5 times I only want it saved to the library once but used 5 places. The issue is more noticeable with large assemblies where manual replacing and renaming isn’t practical.

This has to do with how the STEP file is organized, how the translator exported the file and how Alibre builds the STEP assembly.
 
JamesMC said:
I have found the issue for me seems to be in assembly's with multiple sub-assembly's in them, if I go into the sub-assembly and save it as the new version it seems to work ok, I just then have to go into the main one and replace the sub-assembly's with the new ones.
Click to expand...
I can confirm this behavior with the large STEP file I tested.
Its main assembly (“01”) contains only one sub-assembly (“02”) with 465 parts.

If I first save the main assembly 01 to a desktop folder using the original long file names, I do not encounter the bug when I later open sub-assembly 02 and rename all parts manually or via my script to save them in a new folder.
However, the issue appears when I attempt the same operation directly from the top-level assembly (main assembly 01), either immediately after STEP import or after saving it once with the original names.
Maybe this helps narrow down the cause of the issue.

Unfortunately, this is not really a practical workaround. I often need to import large STEP files containing 500+ parts distributed across 10–50 sub-assemblies, and I do not want to manually rename each sub-assembly separately and then replace them again in the main assembly.
In the worst case, the original file names may already be too long to save them in higher-level folder locations due to Windows path length limitations.

EDIT:
The same issue also affects native Alibre designs that use my own designed parts and sub-assemblies.
If I try to rename files manually or via script from the main assembly layer in the “Save As” menu, I again run into the same problems with ghost files and false duplicate entries in the table and can't fix it.
 
Last edited:
You must log in or register to reply here.
Back
Top