Solid Edge and Solidworks both appear to open reference files only by the file name stored in the parent file, NOT by the full path. For the life of me I cannot figure out how this is a good idea. What a mess this creates. Side note, I understand duplicate file names are bad bad bad, but letting the software silently choose which one to use causes much grief.
Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.
No, it’s SOOOO simple. All you have to do is memorize the 13 different places and conditions where SolidWorks looks for the files. As long as you can follow these steps, you’ll never get the wrong file! I’m sure Solid Edge uses something similar.
(borrowed from the SW help)
Uses any open document with the same name.
If p2.sldprt is in another open document, SOLIDWORKS uses this version of p2.sldprt.
Searches the first path that you specify in the Folders list in the File Locations Options dialog box.
You must select the Search file locations for external references check box in the External References Options dialog box or else SOLIDWORKS ignores the paths that you specify.
D:\aa\bb\p2.sldprt
Searches the path in Step 2 plus the last folder in the path where the referenced document was last saved.
D:\aa\bb\xx\p2.sldprt
Searches the path in Step 2 plus the last two folders in the path where the referenced document was last saved.
D:\aa\bb\yy\xx\p2.sldprt
Repeats Step 4 until the full original path has been appended to the path in Step 2.
This concept of adding one folder at a time from the full path will be called “recursive searching” in the following steps.
D:\aa\bb\zz\yy\xx\p2.sldprt
Recursively searches the first path in the Folders list, then recursively searches the path where the referenced document was last saved.
D:\aa\xx\p2.sldprt
D:\aa\yy\xx\p2.sldprt
D:\aa\zz\yy\xx\p2.sldprt
D:\xx\p2.sldprt
D:\yy\xx\p2.sldprt
D:\zz\yy\xx\p2.sldprt
7. Repeats Steps 2 through 6 for the other folders in the Folders list.
E:\cc\dd\p2.sldprt
E:\cc\dd\xx\p2.sldprt
E:\cc\dd\yy\xx\p2.sldprt
E:\cc\dd\zz\yy\xx\p2.sldprt
E:\cc\xx\p2.sldprt
E:\cc\yy\xx\p2.sldprt
E:\cc\zz\yy\xx\p2.sldprt
E:\xx\p2.sldprt
E:\yy\xx\p2.sldprt
E:\zz\yy\xx\p2.sldprt
8. Searches the path of the active document, then recursively searches the path where the referenced document was last saved.
D:\ss\tt\p2.sldprt
D:\ss\tt\xx\p2.sldprt
D:\ss\tt\yy\xx\p2.sldprt
D:\ss\tt\zz\yy\xx\p2.sldprt
D:\ss\xx\p2.sldprt
D:\ss\yy\xx\p2.sldprt
D:\ss\zz\yy\xx\p2.sldprt
D:\xx\p2.sldprt
D:\yy\xx\p2.sldprt
D:\zz\yy\xx\p2.sldprt
9. Searches the path where you last opened a document, then recursively searches the path where the referenced document was last saved.
In most cases, the path of the active document and the path where you last opened a document are the same.
The two paths are different if you click File > Open to open one document, then drag and drop an assembly from Windows Explorer into that document. The path of the active document is the path from Windows Explorer and the path where you last opened a document is the path from File > Open .
same as Step 8
10. Searches the path where the software last found a referenced document.
C:\qq\p2.sldprt
This is the location of p1.sldprt.
11. Searches the full path where the document was last saved without a drive designation.
This is useful if you save a part with a UNC path such as \machine\folder\p2.sldprt.
12. Searches the full path where the document was last saved with its original drive designation.
C:\zz\yy\xx\p2.sldprt
13. Allows you to browse for the document yourself.
Alright, we need a downvote/thumb down button. Note no purple font.
I’ve had it to my eye balls with what you’ve just copy pasted!
Where in that ridiculous list does it say:
If all else fails, try using the full path as saved in the parent file, you know, just incase they were serious about wanting the next person to use the same thing, maybe.
Well, the full path is actually in there, but - and you’re gonna LOVE this - it’s the next to last option. Not 99, but 12/13. It’s a crazy system, which is part of the reason you can’t screw up your file management or make duplicate files.
One of the things I like about Onshape is that this is never a problem. At least that’s my understanding, not being a real user.
We have PDM which has just been fanning the flames! Migrated data from network shares where the files still are. Nearly impossible to get CAD to only look in PDM.
Also, we’ve migrated to a new vault and there were some (most) of the users that just ignored my instructions of removing old vault view (which still has many files in cache even though they cannot log in) but if Solidworks thinks that’s a good place to go there’s no stopping it, even when the user just did a get latest on the parent file and has all the references in that cache. I figured out how to run a script on remote computers that forcefully removes Vault Views so that has helped. But I need to keep a view of the old vault for the sake of looking up history, I get bombarded with the Log in dialog from the old vault when opening assembly from new vault. I know the assembly was checked in with good refs in this case.
Solid Edge does the same thing, looks a bit different but about the same behavior. I can categorically state that is was much simpler to deal with this behavior before PDM.
edit, Matt, did you forget to color the “and you’re gonna LOVE this” ?
“Where it was lasted saved” what does that mean? Is that their way of saying “according to the full path in the parent file”? or Where it was lasted saved in the scope of the PC I am currently on.
In Solid Edge the references were visible when the file was opened with a compound file explorer, they are listed in Jsites… I wrote a parser so I could index our references for the sake of fast where used searches. I think at ST9 they made that info public with some .dlls that windows indexing service can use (BiDM mechanism I think)
In Solidworks the only place I can find to reliably get what the full path is in the parent file is using Pack and Go. That appears to show me the unmolested path as it was saved in the parent file rather than where SW is going to try to find it.
Yes, of course, I meant to color it sarcastic. Sorry, I’ve fixed that oversight…
I think “last saved location” has to mean last place that the assembly knew that the part was saved. It couldn’t know anything about the part being saved when the assembly wasn’t open, which is part of the problem with file management when you have referenced files.
Absolutely!
I just wish Solidworks would listen to where PDM says to get the refs from. If I understand correctly, PDM updates the refs in the parent file when that file is copied to local cache. That is how PDM can update all the files if a ref file is moved or renamed for some reason, it doesn’t actually update all the files at that time, just the reference records in SQL then updates the file when it is downloaded to local cache?
In any multi-user environment, ALL users NEED to use SAME folder structure.
Same drive letter (local and mapped network drive).
All you need is one user don’t follow this rule to have never ending file referencing.
This apply to PDM and not.
Also apply if software remember full path or not.
I know this will be considered sacrilege by most users, but I have multiple files with the same name. I’ve been doing it for years, and never had an issue with it. No PDM, by the way.
When I start a new project, where I’m not sure what the final design will look like (which is almost all of them), I have a sub-folder with the current date as the folder name.
All new SW files that are specific to that project are saved in that folder. I do not have separate folders for different file types. When we first started with Solidworks Parts, Assemblies, and Drawings all had a separate folder. I don’t know who told them to do it that way, but it was a nightmare. (I was still on the construction crew when that happened.)
When I have a design change I either copy the files to a new folder (again, with the current date as the folder name), or do a Pack and Go to a new folder. I rarely change any file names as part of this process.
When the design is finished I Pack and Go the top level file (which is almost always a Drawing) into the Drafting folder for that project, which leaves behind any files that are no longer used. Then I open that new Drawing, and while it’s open I delete all the no longer needed folders and their contents. By having the Drawing open I make sure that I don’t delete anything I need, but it’s never been an issue.
The only reason this works is that all project specific files are in the same folder, and when I open a Drawing or Assembly the software will first look for, and use, files in the same folder as the Drawing or Assembly. Right or wrong, that’s how it works, and I’m a big believer in accepting and working with things I can’t change instead of wasting energy fighting against them.
Glenn, I think you can get away with that if you are working on projects that never cross, they are standalone and isolated. But if ever you need to open two assemblies from two different projects that both contain files with the same name, the first one you open wins, the seconds loads files in memory first.
Before PDM we had to constantly drive home to the engineers that when you copy Released files you need to prefix the file names with the project/eco number. Of course that led to them using Pack n Go to copy everything with a prefix which in turn led to unnecessary copies of files, that no longer update. Which led to questions like “How do I get the latest updates to my file set”.
Check, done.
It’s not that the software cannot find reference files, the problem is that it’s looking for the reference files in the wrong places and therefore using the wrong files (sometimes)
That’s what we are doing right now.
I rename every single part, that I modify though - which means, that sometimes after re-linking the part I have to do the work twice (add a cfg etc.).
It’s still faster for bigger changes, because working on the network is such a time saver. There was a talk on the World2021 which showed a decrease in rebuild/save/open time of more than 50%. An insane number for large assemblies.
It’s pretty simple, the software stores the file reference’s filename and path in the assembly/drawing. If you rename a file or move it then you have a problem. People are just used to renaming files and moving files/folders however they feel like without understanding the implications. Not sure how any software can handle this better working in a file system, unless it replaces that filesystem with some sort of PDM like feature that monitors every file/folder operations and updates the file references.
Try linking some Excel and Word files together and you have the same problem, only worse since there are less tool to see and work with those links.
Worse when our users copy everything, not just parts they want to change. Unfortunately they are in hurry and Pack n Go offers the path of least resistance which is to copy everything.
You’re right, of course. My projects are stand-alone. Many of them use the same Parts and sub-assemblies, but those shared files are in a separate location, and not copied to the project specific folders. Occasionally we will need to modify one of those Parts for a specific project, but in those cases I copy it to the project specific folder and re-name it before making any edits or inserting it into an Assembly.
I just wanted to make the point that having files with the same name isn’t problematic in all situations.
Yes, I pack&go everything too, because I want to work locally.
Later on I re-link the unchanged parts back manually to our standard network folders.
it is ‘fairly’ easy to do luckily, just remove the extension & change the folder & you’re done.
Every part that I modify, I rename to modified_xxxxxx, thus I know what I need to change on the network drive (or make new part # for that):
Note no purple font.