File Management

I thought it would be useful to take a step back and look at the basics of using SolidWorks effectively. The ten essentials of SolidWorks; not just a list of beginner topics, but concepts and tools inside SolidWorks that once learned, will help you survive your day to day projects. Take a look at these and brush up on the ones you don't know as well as you would like. You will be more productive and work the way the tools were intended, instead of fighting them. Here's a quick list of my ten essentials you must understand to use SolidWorks effectively:

·        File Management

·        FeatureManager Design Tree

·        Templates and Sheet Formats

·        Design Intent

·        Two Dimensional Sketching

·        Constraints (Relations and Mates)

·        Configurations

·        Multiple Bodies

·        Custom Properties and BOMs

·        In-Context Features, Bottom Up / Top Down

  

Let's tackle these essentials one at a time, starting with the first " File Management" in this issue which I have split it into five parts.

 

Learn File Management Basics

One phrase that I always keep in mind when working with SolidWorks files is "single point database".  In other words, data is stored in only one place and everything else that needs that information references it from the original.

 

Let's first take a look at the specific data or information contained in each file type and explore how these file types are associated. 

 

The part files (.sldprt) contain the basic geometric information. This includes information such as chronological history and shapes of all the features, the material, and custom properties specific to the part. The part file does not know (or need to know) which assemblies use the part, or what drawings of the part exist. In other words the "where used" information for a part is not needed in the basic SolidWorks file structure. Note: This "where used" information is tracked in product data management (PDM) solutions, and can be searched for in SolidWorks Explorer.

 

The assembly files (.sldasm) contain information such as quantities, where the parts are located and mated in the assembly, and exploded view definitions. The assembly does not store the part information because it references the part files for the specific information it requires such as their geometric information. I like to think of the assembly as a classroom. Inside this classroom there are tables, just like in an assembly there are parts. The assembly knows that it contains let's say 10 instances of a table, and where they are located in the classroom. The bottom of the legs of the first table are coincident to the floor of the classroom, and the front edge of the table is 12 feet from the front wall of the classroom, and the right edge of the table is 6 feet from the right wall of the classroom, and so forth.

 

The drawing files (.slddrw) contain views of any combination of parts and assemblies. The drawing files contain information such as sheet format data, the component names that are shown in each drawing view, and their view orientations. The drawing also needs to reference the parts files for their geometric information, and assembly files for the part arrangement, and exploded view definitions. 

 

That's why when you send a drawing or assembly file you need to send all the referenced component files as well. Tools like File, Pack and Go, and the reliable File, Find References are designed to gather all the files needed, to make sure all the associated files are copied and sent together. An exception to this is without the part files you can still open up the assembly and drawing files as Quick View. This allows you to pan, zoom, and rotate the view orientation (as applicable), but not edit the assembly or drawing.

 

When using the Pack and Go tool and you use the option to zip up the collected files, I have seen problems unzipping the files later if you use Windows Explorer to unzip. To work around this you can either unzip with a 3rd party tool other than Windows Explorer, or use the Pack and Go tool to gather the files into a folder, and then zip (compress) the files to be sent in Windows Explorer.

 

To illustrate how these file associations work, let's go over a simple example of an assembly consisting of a dowel pin pressed into a plate.  An exploded isometric view of this assembly is to be shown in a drawing.

 

The dowel pin part file contains geometric information such as the diameter and length of the pin. The plate part file contains geometric information such as the thickness, length and width, and location of a hole in the plate.

 

The assembly file knows it contains two parts (one plate and one pin), the mates (the pin is concentric to the hole in the plate), and the exploded view information (the pin is separated 1" from the mated position along the axis of the pin). The assembly file needs to reference the part files for all the geometric information.

 

The drawing file contains an isometric view of the assembly. The drawing file stores the filename of the assembly, the view orientation, and display state (shaded isometric view of the exploded assembly). The drawing therefore needs to reference both the assembly for mating and exploded view data, and the pin and plate parts for geometric information.

 

What about associatively? If you open the pin part file, double click on the outside surface of the cylinder, change the diameter dimension, and rebuild, the geometric information is changed. If you then jump to the assembly file, the assembly reflects this new diameter. Likewise, the drawing will display the updated diameter in the exploded view of the assembly. That's because it's the same geometric information for the pin used in the part, assembly, and drawing file. In other words, the assembly and drawing files both reference the geometric information contained in the part file.

 

The exception to all this is the use of internal parts within the assembly file. When creating a new part while in the assembly using Insert, Component, and New, notice you are not asked for a filename. This is because the new part is considered an internal part. In the FeatureManager Design Tree these internal parts have [brackets] placed around the part name distinguishing them from the external parts. All of the same information is contained with the part definition, but the part file information is not stored as a separate file (.sldprt), instead this part definition is stored with the assembly file (.sldasm). Essentially you have your assembly file and inside of that file are the part definition(s) as well. Although confusing at first, there are advantages to this way of working (easy to rename the part), and it turns out, you can save the part definitions externally at any time. Thus you are back to the part and assembly files all written as separate files to the disk.

 

Make sense? Clear as mud?

 

Understand the difference Between Save As and Save As Copy

 

OK, now let's move on to another tricky concept. Save As and Save As Copy. Let's keep it simple, and say you want to rename a part file. When you try to invoke File, Save As on a part file that is used in an assembly, you need to understand what will happen to the instance of the part that is currently in the assembly. Do you want to change the name of the part currently in the assembly as well, or do you want to change the name of the part file, but keep the part referenced in the assembly as is? The way you handle this depends on whether the assembly or drawing file is currently open. 

 

If the assembly file is open, when you invoke Save As, you get the message:

 

This document is being referenced by other open documents.  "Save As" will replace these references with the new name. Check "Save As Copy" in the "Save As" dialog if you wish to maintain existing references.

 

This message really explains the entire situation, but let's break look at it one piece at a time:

 

This document is being referenced by other open documents. This explains the part file that you are trying to rename is being referenced by, or used in a currently open assembly (or drawing). 

 

"Save As" will replace these references with the new name. This simply means if you proceed with Save As on your part file (essentially giving the part file a new name), SolidWorks will ALSO change the file that is referenced in the assembly to the new file name. The old file still exists on your hard drive, but the assembly will now contain the new part file, not the previous part file. 

 

Check "Save As Copy" in the "Save As" dialog if you wish to maintain existing references. This is saying that if you want to keep the assembly as is (using the original part file), and just create an additional part file, be sure and check the Save As Copy box in the Save As dialog box. Checking this box will create the new filename and leave the original part and the original assembly as is. Also note that while this creates the new file, the old file remains open. If you want to edit the new file, you will have to open it. This is opposite of traditional Windows Save As, where the old file is closed, and the new file is opened.

 

If the assembly file is closed, when you invoke Save As on the part file, it's easy to understand. With all referenced assemblies or drawings closed, you should NOT get the above message, and Save As will create the new filename and leave the original part and any assembly or drawings as is.

 

Using Save As on an In-Context Assembly (Ugh!)

 

What about creating a copy of an assembly that contains in-context features? An in-context feature is a feature of one part in the assembly, which was created in the context of the assembly (in Edit Part mode), that uses a different part in the same assembly as a reference. This could be a gasket created by offsetting the edges of the housing, or a flange created by converting the edges of a hole pattern on an adjacent flange. 

 

This relationship between the three components (part1, part2, and the common assembly) is unique, and I would avoid using Save As or Save As Copy on any of these in-context components. Instead I would use SolidWorks Explorer to rename the components, and you will be able to maintain the in-context relationships. Or you could use File, Find References to copy of the entire assembly with all components to a new location. This way you have two copies of a fully functional in-context assembly. You could then rename the components in either folder with SolidWorks Explorer if desired.

 

If any of this is confusing, just mock up the situation with a very simple test part(s) and assembly. Even though I have been using SolidWorks for a while and I still use this method quite often.

 

Use Unique Filenames

 

Warning: some real world advice to follow. There are numerous reasons to give each and every file you create a unique name. It's easy to call a file angle.sldprt or bracket1.sldprt, but after a while you'll end up with hundreds of folders each containing unique parts with the same filename. Where this really haunts you is during a subsequent implementation of any PDM solution.

 

Define a Good Project Folder Structure (Without a PDM System)

 

One last topic for this issue of SW Tips/Tricks; Defining a good plan for basic project directory structure. I like to keep it simple. Note that this is for people NOT using a PDM system.  With PDM systems this method is unnecessary and causes problems.

 

Let's start a project on May 20, 2009 in a folder called "Project Gizmo - Latest Working Copy" and at the end of the day/session gather all the files and copy them into a new folder. Do this by opening up the top level component(s) and use File, Find References to copy all files associated with the project into a folder called "Project Gizmo - 2009-05-20" (the European style date will sort better when there are lots of folders together). Now you have a folder that is a May 20, 2009 snapshot for your project.

 

The next time you work on Project Gizmo, at the end of the day/session repeat the File, Find References process and copy all the files associated with the project into a new folder with a new date. This gives you a folder that is the next snapshot in time (or revision) for your project.

 

File, Find References is also useful for double checking your assembly components file locations from time to time, or to double check that you have all the required files in one location before you depart for a trip. To do this, just open the assembly, and then use File, Find References to glance at all the file locations and make sure the locations are what you expected.