where does it open the components from?

[KSHansen]

I'm having a lot of trouble understanding how Solidworks functions with regard to opening components.

I just opened an assembly. How do I find out where the components were opened from? Let's say this is important because there are several copies of the same part in different locations. I did a right-click on the component in the model tree, and chose "External Reference," and it tells me the original folder that they were in when I first made the assembly.

In doing research with The Google, I learned that you can tell SW were to look, using Options > File Locations > Reference Folders. Woulda been nice if someone had showed me that one. This is just for my own machine. Is there a way for the entire org to follow the same list?

Search order:
1. model in RAM
2. follows reference folders
3. looks in the last folder I looked in
4. last folder SW looked in
5. folder path used when the assembly was last saved

So here's another question... what do I do when move an assembly and its components? I'm used to working in a local folder, and when the project is complete, distributing all the files to their homes according to our file structure. It sounds like as long as all of those folders are in all users' Reference Folders lists, this will be fine. Is that a fair assessment? Once I move everything, should I reopen it in place, and save it, just in case another user doesn't have all the folders listed? Will that help?

Do you have any other tips for me?

[mattpeneguy]

I remember very early on when learning SW that there are something like 12 different locations SW looks for files that may not make any logical sense. That's why it is very important to have unique filenames for all assemblies and parts.
If you need to make a copy of an assembly, I recommend using Pack and Go and use a prefix or suffix to make sure the filename is distinct from the original.
If you can setup PDM, that can help.

Here's an interesting quote from someone who knows the software a little better than me:

"NOTE
Okay, this should scare you a little bit. Solidworks looks for referenced documents in one or two other places before it looks in the last place you left them. This means that there is sometimes the potential that Solidworks will find a part with the same name as the one you are looking for, but in the wrong location. This is one of the reasons why it is so important to have unique filenames, and to avoid multiple versions of the same part lying around in various folders. I hope that got your attention, because it is one of the most important pieces of Solidworks file management information that you will learn in this or any book."
--p. 51, SolidWorks Administration Bible 2010, Matt Lombard (That's @matt, the guy who runs this forum)

I recommend that you buy that book, or better yet his new one, Mastering Solidworks. Because if you didn't know about unique filenames being so important, there's probably quite a few other details you may want to look into, also.

BTW Matt, that was very easy to find, I knew you'd have "unique filenames" listed in the index. Good job!
Also, for whatever reason the indent tag didn't seem to work, so I used the op tag instead.

[SPerman]

it is so important to have unique filenames

This cannot be emphasized enough.

[CarrieIves]

To tell where the files were opened from, in your assembly, select "File, find references". This will list the full path name for all the files in your assembly.

We work on network drives. I try to keep a flat folder structure for each project, but there have been times that wasn't maintained. To tell if parts were opening from the right place, I use "File, Find references".


Before I open an file, if I am concerned about where it is pulling a model from (or need to change something), I can edit the references.

I find both of these tools helpful when trying to understand what SolidWorks is up to.

[mattpeneguy]

To tell where the files were opened from, in your assembly, select "File, find references". This will list the full path name for all the files in your assembly.
image.png
We work on network drives. I try to keep a flat folder structure for each project, but there have been times that wasn't maintained. To tell if parts were opening from the right place, I use "File, Find references".


Before I open an file, if I am concerned about where it is pulling a model from (or need to change something), I can edit the references.
image.png

I find both of these tools helpful when trying to understand what SolidWorks is up to.

Always be suspicious of what SW is up to...Never trust SW...

[KSHansen]

Always be suspicious of what SW is up to...Never trust SW...

This is absolutely true. It does not have my best interests in mind.

[KSHansen]

To tell where the files were opened from, in your assembly, select "File, find references". This will list the full path name for all the files in your assembly.
image.png
We work on network drives. I try to keep a flat folder structure for each project, but there have been times that wasn't maintained. To tell if parts were opening from the right place, I use "File, Find references".


Before I open an file, if I am concerned about where it is pulling a model from (or need to change something), I can edit the references.
image.png

I find both of these tools helpful when trying to understand what SolidWorks is up to.

Thanks, Carrie, that's awesome! I would never have found those things.

[CarrieIves]

From the Find References, you can also save the list out or print it. We've had some messes to untangle at a previous job where we had a big assembly and had to go through and make sure everything was looking at the right thing.

Good luck.

Carrie

[KSHansen]

To those telling me I should only use unique file names, yes I know. But I have to... it's a long story. It involves making a copy of the assembly where I need to swap components without actually deleting them from the assembly because then I'd lose the configurations and design table.

On a tangent, I learned how big a design table can get before it starts causing you trouble. (Not nearly as big as what I'm used to working with in Creo.)

[JSculley]

I remember very early on when learning SW that there are something like 12 different locations SW looks for files that may not make any logical sense.

It used to be a 13 step algorithm back in SW2013. In SW 2022, it is now down to 8 steps

[bnemec]

It used to be a 13 step algorithm back in SW2013. In SW 2022, it is now down to 8 steps

So is there hope that by 2024 they'll have it down to where it belongs? Two steps; one, is it open in memory? And two by the full path stored in the parent file. Done

[DanPihlaja]

Here is a pretty good article covering it:

https://blogs.solidworks.com/tech/2014/ ... works.html

[Frank_Oostendorp]

Whatever search routine SolidWorks is using, 13 steps, 8 steps, it only get's active when the referenced file is not in the location the parent file had saved internally.

When opening a referenced document, SOLIDWORKS performs a search to locate the document. For example, this search may occur when you open a drawing and the referenced assembly cannot be found

The search routine is something you do not want, SolidWorks opening a random file.

This can be in the memory as well, and we all know how the memory is well-handled by SolidWorks. So basically two rules are mandatory:
- use unique file names, so there are no "any documents with the same name".
- do not move around SolidWorks files around in an incorrect way, do it in a way the references stay correct.

[KSHansen]

- do not move around SolidWorks files around in an incorrect way, do it in a way the references stay correct.

What do you recommend?

[KSHansen]

I have a local project folder where I'm designing parts and making assemblies. Once I know what I've got, and everything is complete, I move them to their designated locations on the network. Parts go to their folders with subassemblies and top-level assemblies going to theirs. The first time I did this, I opened all the component first, then the subassemblies, then the top-level assemblies. Then I saved everything, thinking that SW would remember the paths. I guess I didn't understand the eight-step method, because the next time I tried opening the assembly, it couldn't find the components.

So I added all the network folders to my Reference Documents, per the blog post that Dan mentioned...

2) REFERENCE DOCUMENTS PATH: This path is defined at the SOLIDWORKS User Level in your System Options. Go to TOOLS > OPTIONS > General Tab > FILE LOCATIONS category. – Select REFERENCE DOCUMENTS from the list. * This one is SUPER COOL! If you set a path in the REFERENCE DOCUMENTS list, SOLIDWORKS will actually look here before looking at the original path or even in the same folder that the assembly or drawing are located in!

After this, the assemblies opened with no problems.

So is there hope that by 2024 they'll have it down to where it belongs? Two steps; one, is it open in memory? And two by the full path stored in the parent file. Done

I think it should be three steps. I'd like it to look in the folder we're working in before sending it down the search path. That's what Creo does.

[bnemec]

I think it should be three steps. I'd like it to look in the folder we're working in before sending it down the search path. That's what Creo does.

I understand, but not everyone stores files like that. What you explained made me cringe a little; it's all based on use case which is determined by the business.

It would be nice to turn all that off for those of us that do not put files in project folders. Files have part number or serial number file name and folders are broken out by first x digits in file name to limit the number of entries in the folder. The entire data set is available for use in any product/project. This looking in a directory structure based on the directory the assembly (parent file) is a complete hindrance in that case. The part files are almost never in the same folder or a subfolder of the parent.

[nordstjernen740]

Tangent advice to the above topic:
Unique files names are so so important. I am sometimes astounded that solidworks doesn't really have any built in tools for helping you use unique file names (unless you have pdm) and even in pdm all of the example datasets that solidworks constantly uses in their presentations and "how toos" have horrible naming systems. bearing.sldprt, frame.sldasm, trussdrawing.slddrw etc. etc...

Uniqueness of filenames is far far far more important that readability and use of filenames as a "description". There are several easy methods to display title, description, and other properties of documents apart from relying on the filename to convey this information. (even without pdm)

When I work outside of a pdm environment I have a nice workaround that ensures a unique filename for every file you ever create where this feature is even remotely important(even for nonsolidworks files). the trick is to install a third party software that you can configure to either insert text on command and/or insert text to your clipboard. You want to set this up to insert a specially formatted timestamp where ever you need it.

Autohotkey is what I use and is widely used and respected freeware for the most part as far as I know. Like anything I'm sure it can be abused, but not any more easily than a solidworks macro. IF you are in a situation where your organization allows freeware, the autohotkey timestamp to clipboard is really easily configurable and guarantees a unique file name at your fingertips at all times. If you insist on descriptive filenames you can always put the timestamp first and short descriptive word second.
Alternatively, there are several simple websites from which you can copy and paste timestamps and/or guids on demand.

[Frank_Oostendorp]

What do you recommend?

Kill the automatic search routines of SolidWorks, as far as it can. (Windows 10 Indexing keeps messing up things)
Open the highest level of assembly and its drawing, save both to the location you want them to bee.
Next start opening each subassembly and its drawing, and save these to their new location XXX.
Save the highest level files, the path to the subassembly should be updated to the new location XXX.
So repeat this with all sub-assemblies and parts.
Finally, delete all files from their initial locations.

I keep track of this process on a note, because system crashes in the past made me forget where I ended up
Handling huge projects take a lot of time, but keeping it clean and simpel is an investment for the future.

[bnemec]

Kill the automatic search routines of SolidWorks, as far as it can. (Windows 10 Indexing keeps messing up things)
Open the highest level of assembly and its drawing, save both to the location you want them to bee.
Next start opening each subassembly and its drawing, and save these to their new location XXX.
Save the highest level files, the path to the subassembly should be updated to the new location XXX.
So repeat this with all sub-assemblies and parts.
Finally, delete all files from their initial locations.

I keep track of this process on a note, because system crashes in the past made me forget where I ended up
Handling huge projects take a lot of time, but keeping it clean and simpel is an investment for the future.

Frank, from reading that I think you would like how Solid Edge, Design Manager works.

[Frank_Oostendorp]

Frank, from reading that I think you would like how Solid Edge, Design Manager works.

You must have read my mind. Just started studying the Siemens CAD software available. Last time I used Solid Edge was 20 years ago, so it might have improved a bit. SolidWorks Solid Edge. Probably have to invest some time to do research.....

[bnemec]

You must have read my mind. Just started studying the Siemens CAD software available. Last time I used Solid Edge was 20 years ago, so it might have improved a bit. SolidWorks Solid Edge. Probably have to invest some time to do research.....

We just left SE and went to SW, mostly to gain PDM. To be frank, I don't know that one is better than the other, each has it's own things. Things to make you smile and things to test your humanity. To those that can use more than one CAD system or jump back and forth (nice use of the emoji!) I'm envious.

[mike miller]

........To be frank, I don't know that one is better than the other, each has it's own things. Things to make you smile and things to test your humanity..........

I'd say you're right..............with some qualifications. It all depends on your business model and the type of work you do.

For us, the big draws to SE were:
-Synch (better workflow than anything SWX will ever have)
-BOM control (lightyears ahead of SWX)
-sheet metal is very, very good- especially with Synch
-drafting functionality and stability (things like dimension tracker and the way it handles model views)
-rules are enforced much better to allow less user error
-and of course the direction SWX is headed

The drawbacks of SE are:
-UI is much more cryptic and harder to learn
-fewer window dressings and bells than SWX
-configurations are stored in external files and not all-in-one like SWX. This is a double-edged sword, for sure.
-API programming is more difficult for many reasons
-Frame (weldment) environment is behind SWX, IMO

Still easily worth it though. I enjoy using SE and find it less frustrating overall.

If you check out Teamcenter Rapid Start, you'll find out that it's not a bad way to go at all. The only real drawback is their named-user licensing model. Otherwise it is extremely capable and tightly integrated with SE (or SWX if you want).

[bnemec]

I'd say you're right..............with some qualifications. It all depends on your business model and the type of work you do.

For us, the big draws to SE were:
-Synch (better workflow than anything SWX will ever have)
-BOM control (lightyears ahead of SWX)
-sheet metal is very, very good- especially with Synch I didn't know SW could be this far behind, SW doesn't even have a dimple feature
-drafting functionality and stability (things like dimension tracker and the way it handles model views)
-rules are enforced much better to allow less user error
-and of course the direction SWX is headed
- you missed the horrible selection methodology in SW of let anything be selected then offer what to do.
Operational workflow in SE is so much better in that I select what I want to do and SE applies selection filters automatically for me.
- relationships/mates in assemblies can be made to implied geometry any time, not just axis we kind of fell on our face with this.


The drawbacks of SE are:
-UI is much more cryptic and harder to learn
-fewer window dressings and bells than SWX
-configurations are stored in external files and not all-in-one like SWX. This is a double-edged sword, for sure. we have found some use for configs in SW where SE we just had another file I'd vote for SW on this one.
-API programming is more difficult for many reasons look up Jason Newell, not sure that he's still active in SE API but anything you need to know about SE API he has already covered. I found some things terrible in SW API that were simple in SE and the opposite is also true. Example, pdf in SE is just a few lines and do not need to load any refs or even show the UI pdf in SW is a PITA. On the other hand DXF in SE is a cluster, dxf in SW is simple. I think it's because SW drawing environment is just bad.
-Frame (weldment) environment is behind SWX, IMO We never use frames or weldments so I don't know, we're all one part per file.

Still easily worth it though. I enjoy using SE and find it less frustrating overall.

If you check out Teamcenter Rapid Start, you'll find out that it's not a bad way to go at all. The only real drawback is their named-user licensing model. Otherwise it is extremely capable and tightly integrated with SE (or SWX if you want).

[SPerman]

To me, the driving factor isn't the features in the product, but the quality of the company. Siemens appears to be embracing this market, while DSS is doing everything they can to alienate the traditional SW user.

[bnemec]

To me, the driving factor isn't the features in the product, but the quality of the company. Siemens appears to be embracing this market, while DSS is doing everything they can to alienate the traditional SW user.

DSS to SW users: "Hello, we're from Dassault and we're here to help."

If you get it you get it...