The next lesson in top-down design: Document management
May 4, 2010
Proper organization of files and folders makes a designer's life a lot easier.
Our design project has captured the overall inspiration for the Shashlik Grill (see Figure 1). We have many of the major components modeled parametrically, but we still have several features to invent and model.
As the number of components increases, pressure builds for us to develop a good document management scheme. Our goal is to serve several masters—invention and CAD modeling, purchasing, production, and product support.
(The usual disclaimer: If you’re not using the same 3-D CAD software as I am, then you’ll have to translate some of the terminology. However, the concept of parametric modeling is widely applicable.)
The main tool we use for storage and organization is the operating system—Windows®, in most cases. Every operating system I’ve encountered stores documents as files and folders. The combination of drive letter and nested chain of folders is often referred to as a path.
When it comes to naming, I’m of the opinion that shorter is better. File names get typed into fields in forms, and long file names and paths generally become a nuisance.
Folders are easy to create and provide a reasonably good way to separate one project from another. I’m keeping most of the files for the grill in a folder called Shashlik Grill. I frequently create subfolders that capture the revision of a project as it moves through the design evolution. These subfolders are named Rev A, Rev B, and so on.
The date of revision sometimes ends up being important as well. The operating system does a fine job of putting dates of creation on the folders. However, when the folder gets copied onto a new drive, the date of original creation can get lost.
When I’m naming a project subfolder, I frequently include both a revision and a date—something like Rev A 06-30-2010. That way, when it gets zipped up for archiving, it is easier to interpret when the design work was done rather than simply when the operating system created the files.
My rationale for naming files is slightly different from that used for naming folders. I want my folder names to be pretty easy to interpret by humans. I want my file names to benefit the vagaries of the 3-D CAD software that I’m using.
We could name a file Shashlik Grill Lower Pan FMA-SG-0100 REV A.sldprt, but I don’t do that for two reasons:
The 3-D CAD software I use features three distinct types of files—parts, assemblies, and drawings. Parts are grouped together into assemblies. Parts or assemblies are referred to as components. Drawings are the 2-D representations of components. When the software opens a drawing, the drawing file has a pointer that identifies which component file to use when displaying the drawing.
If my CAD file for the component has a revision in its file name, and if I change that revision, then I also have to update the pointer in the drawing file to let it know that it now has to look for a different component file.
Similarly, an assembly file is also a collection of pointers to other components. If the file names for the components are changed without keeping those pointers up-to-date, the assembly file will be corrupted.
One or two work flow procedures within the CAD system make the process of changing component names relatively painless. However, changing file names within the operating system in certain ways will aggravate the CAD system. From experience, my best practice is to minimize the need for renaming files.
It is worth noting that the entire path is used in these pointers to components, so moving a file to a different drive, changing a folder name, or renaming a part file can all cause the CAD system to lose its mind, so to speak.
In general, if you need to rename or relocate a file, do so using tools and procedures provided with or recommended by the CAD system. Be very careful about simply using Windows to rename or reorganize files and folders. I’ve heard CAD jockeys use harsh language because of busted file pointers.
File properties can let you have short file names and still have happy people.
All Windows documents have file properties. A file property has two elements—a name and a value. The author of a document has the option of using the file properties—creating them or referring to them is entirely optional as far as Windows is concerned.
The CAD software I’m using makes a small improvement to Windows Explorer. If file properties Description and Revision are defined, then their values will be displayed by Windows Explorer when the mouse is hovered over the file name. That way, people can see a lot of detail without packing it all into a long and hard-to-manage file name.
The same CAD software also employs file properties to fill in title blocks on drawings and to populate columns in bills of materials. Data such as source, cost, manufacturing process, material, and so forth, can all be entered into file properties.
In Part VI of this series, we’ll test some of the parametric features of our design by stretching the shape for better material utilization as well as better shipping container size.
Keep in mind that this top-down modeling technique we’re using is not the only way to do this work. It may not even be the best way in every situation. However, when it comes to virtual prototyping, it is efficient to use parametrically driven features. It takes some time to set up initially, but it will pay off later by speeding the revision process. The use of reference geometry to control parametric features reduces the complexity of figuring out what drives what.
Gerald would love to have you send him your comments and questions. You are not alone, and the problems you face often are shared by others. Share the grief, and perhaps we will all share in the joy of finding answers. Please send your questions and comments to email@example.com.