I have seen, on more than one occasion, an assembly that has multiple cyclic references in an assembly. Now, I totally understand that when you’re under a deadline, it may save time initially to just copy a part to use for another assembly as opposed to searching your vault, especially if you have a large data set that can take a considerable amount of time, also assuming the description is incorrect, etc. However, as previously noted, while you may be saving time initially, the implications to having duplicate parts can be astronomic, several versions down the road, especially if the assembly is to be used in multiple other upper level or parent assemblies ranging from several broken references to system stability (crashing) and slow operation. With this concept in mind, we will review the implications of duplicate files and cyclic references from within a vault to hopefully mitigate you struggling in the future.
Here, we have an assembly named (Block_Hardware Bolt). We have two bolts (FHCS 1 X 5) that are assembled into the block (block 2 hole) as shown. It is wise to consider this assembly in the manner you might have a directory with standard hardware that is not the toolbox. We can see that the references are directed towards our hardware directory.
Likewise, suppose that once you have your vault up and running, you get to a point where you want to add a toolbox. So, with that concept in mind, we have the following assembly (Block_Toolbox Bolt), which is represented in the concept that this is an assembly with of the exact same named bolts, (FHCS 1 X 5) that are assembled into (block 2 hole). Also, we see that the references are directed towards our toolbox directory.
Finally, at some point during our workflow, the two assemblies with the same children and names cross paths in our workflow. The issue at hand here as noted earlier is that if same names with different files path occur in a parent assembly, you will have broken mates. This is because SOLIDWORKS attempts to solve the issue where it should find the mates and from which reference, which can make for extremely slow loading and saving.
Now, you may be asking yourself, “Why doesn’t the assembly just read the mates and open them from where they are located?” Well, this is exactly the problem with this situation since the background coding of the SOLIDWORKS file references is read in a sequential order, thus reading the first file name and thinking the second one in this case is read from the same location; but as we can see, it will inevitable fail, as the names are the same but with two different file locations, reading a single location. However, all this behavior can easily be mitigated if unique files are always throughout the vault no matter the directory location even if in a toolbox location in your vault.
PLM Support Engineer