It’s been my experience that some software actully create unique IDs assigned to every part that is created. Then the user has the ability to:
Load from search directories..
Load As Saved
From Folder
This tells you how the system is going to find files. You then can set behavior of the load. What to do when I find a file who’s name matches.
Allow Replacement
Or Fail to load
This is defined by the matching the UIDs. If they original and new file have the same UID the software loads the file. If they don’t match it will not load.
This ensure yo uare not loading Block.prt in Project1 folder instead of the Block.prt in Project2 folder.
This just goes to show that if SW or other CAD tools don’t think of this stuff in advance..then you have to come up with some other “work around”..which SW is notorious for!
SolidWorks has internal IDs. It can tell the difference between a copy of Part1 and a part created and named Part1 independently, but it doesn’t use that ID for finding files, just telling you if the file you found is definitely the wrong one. It can’t tell you if it’s the wrong copy, just that it was never really associated with your referencing document.
All of this is manageable manually, but you have to be really disciplined and absolutely understand what is going on. PDM is the best way, but some of the new CAD packages have baked-in PDM, so all of this very Windowsy hunting around for referenced files becomes a thing of the past.
The problem is that there is no single CAD product that gets everything right:
Finding files by internal ID would probably be a big performance hit. The assembly would have to scan file’s internal information and I imagine this is much slower than just finding the file via filename.
Inventor has a built in project file tool that looks good at first glance. You can’t just rename files in the project tool (which would make sense), you have to open the file in the separate Design Assistant which kind of resembles SolidWorks Explorer. The “Rename” was greyed out for some reason and the online help made it look way more complicated than it should be. Renaming them in Windows Explorer broke the links just like SolidWorks.
This is one of the things that people that move from SW to IV HATE and one of the things that people moving from IV to SW go “HOLY !@!@$ are you serious…it just decides what file it wants to open?!”
I can’t count the times that people I know did some work on IV and came back saying “Man that software sucks” and 99% of the time it was because they did not grasp the concept that IV works in well organized and defined projects. You can’t just willy nilly add in files from anywhere with any name or any file that “Seems like it will work”. Either the file is in the defined directories and the file matches…or it tells you you’re an idiot
I think I’m on the same page. I’d rather be informed that I’m an idiot so I can fix it than have the software think for me and find a file it thinks is what I want. I would like a “tell me I’m an idiot” file reference setting something like “open the path referenced in the parent file or mark the ref as missing” And be transparent as to where the reference is supposed to be. Instead the default (and non configurable) behavior is to find a file, assume it’s correct and update the references when the parent file is saved.
You mentioned “well organized and defined projects.” We cannot keep files in “Project” directories because our files are used all over the place, across >many< projects so it would be nonsensical to have files in Project Directory structure. Although this seems to be an assumed industry standard based on how the program searches for references also, behind the scenes in PDM directories are called Projects. Anyway, when we started with PDM we considered not having a directory structure for the general product data (files that would share a workflow and data card) just dump them all in one directory, after all the folder structure only exists on the clients cache, the files are actually archived in secret hexadecimal folder structure on the archive. But since there is still some browsing (even if just in loading the open or save file dialogs) we wanted to keep <~2000 files per directory; so it is broken down by file name.
Just me I guess. It sounds like most users feel that the software should fix broken refs at all costs.
I’ve mentioned on the other forum that SW is unstable and buggy for two big reasons. It tries to be all things to all people and is willy nilly with it’s file structure. These two things lead too all the massive inconsistencies you see and a plethora of things that you “Can do”…“But probably shouldn’t”, assuming you wanted a stable model.
I can say that IV is far more “Strict” in both aspects. It far less often will allow you to do something that later will end up with a complete and utter meltdown. It still allows things like that to happen, just far less often. More often than not you’ll get the…“Yeah, nope…I’m not going to let you do something that stupid”
I assume you mean working outside PDM as it won’t allow duplicate filenames and thus it could (almost) never load the wrong file. The only weird exception I can think of would be if a user took it upon themselves to store some files outside PDM while working on files in PDM.
Before PDM, I spent years managing this manually on a network drive. This took adhering to a rigid process and a lot of training to end users on what not to do. We are like you, we don’t have isolated projects but instead numerous products that share many components. In this environment without PDM you have to use the “File Locations/References” and it’s search rules to manage files undergoing ECO changes thru a release cycle. In order for that to be effective you have to have a read-only folder structure that the users can’t change.
Without the search paths defined, the software always looks where the reference was last located when the assy was saved, if it can’t find it there, then it defaults to the same folder the assembly was opened from. The one caveat to this is that what’s loaded in a memory always wins. If I have a part called “Bar” on my desktop and I open it, then I decide later to open an assembly from anywhere else and it contained a part with that name, the file in memory is used. The software does warn you that the internal ID does not match and defaults to suppressing it, however I notice that users often don’t pay attention to it…and they like to click that box to “Don’t show again”.
Users are lazy like that. They just want the software to work and not have to fiddle with where files are and what they are called. Training is the first key but the second key is forcing them to fix their mistakes, otherwise it never gets committed to memory.
“People will not change until the pain of not changing is greater.”
I think we missed the first lines:
Paths to referenced files are in parent documents. The search routine starts if the referenced file is not at the expected location, stated as “missing referenced document”.
True, except if you have “Search external references in” checked and you have paths defined. It will search there first and go thru that recursive search routine. That failing it will search where the save path in the assy says it was last located.
I didn’t read the whole thread, but be warned, pack and go can fail, and still point to the original file location. My VAR told my my file structure was too complicated.
I’m relatively new to Solidworks and there are many intricacies that I have yet to find. If I’m not mistaken I have this set the way you suggest so that SW should first use the path stored in the parent file?
Then the next problem is all the other SW installations may have this set differently. Before PDM the file was either on a network share that we all had access to or it was on the saving computer’s local drive(s), so either the opening computer had it or not and it was crystal clear when the parent was looking for file not on network share. I’m not saying that was better or PDM is worse, its just that the “what the heck is going on?” question becomes harder to answer. PDM has added a couple layers of complexity from what I can understand several things can happen that many users don’t notice.
on check in of the parent, if a ref is not in the vault PDM will just ignore the reference, like it was never there
if the parent file is ref a local file but that name also exists in vault PDM will resolve the ref to the filename that’s already in the vault at check in (I think)
When importing a large assembly (x_t and 3D interconnect off) there are a LOT of files saved in a short time, if we have found that if this is done in a vault location while “On Line” PDM will sometimes miss a bunch of these files and they remain as . That is one potential reason why there may be duplicate filenames, since these are dropped in the same location as the imported file they may be in a not ideal place. Then I found out that even though PDM is set to delete local files, (which only applies to read only files) does not delete these files because they are not read only as they were never added to the vault so PDM didn’t set the read only file flag. So the user unwittingly has duplicate file names that are not in the vault but the path looks like they’re in the vault. There are no refs to them in PDM because they are not in the vault, other uses do not see them because they are local only and the person on that computer doesn’t realize what’s going on.
Next, when another user opens the parent assembly SW will do it’s best to find that file, if it can (unfortunate) and the user fails to notice the dialog that disappears in 10 seconds that SW is using some other file now they are unaware of what’s going on and think I’m going to yell at them for not getting files as referenced.
Yes, except what’s already loaded in memory is always number 1…PDM or not. This bites users more than you think if they are copying stuff around but not renaming it.
All reference files need to be in the vault or about to be added with the assembly. This setting on the group should prevent checking in an assembly or drawing with references outside the vault.
Not for the same reason, but we train users to import files on their hard drive outside PDM so as not to create all of those files. The reason we do that as we may not add all of those files to the vault. Often an external vendor assembly we make all components “Virtual” since they don’t have our part numbers, just the assembly. They import and cleanup then move to the vault. It’s faster and cleaner on the database as even files they don’t check in are still recorded in the DB as a version 1, even if they delete them.
Only thing I can suggest is to create an environment and training that minimizes the chance to have any duplicate files. If there isn’t another copy floating around, then it can’t “find” the wrong file. Easier said then done, right? When this comes up, I instruct the user and what they did wrong and how to fix it, usually that painful lesson sticks since they won’t want to repeat the experience…usually. Again, I don’t know your landscape so there may be good reasons for the copies.
Again, I don’t know your landscape so there may be good reasons for the copies.