One person who commented on my “You Need a PDM Tool” post asked if I would go through manual file management recommendations for people who really don’t have any choice. This is a response to that comment.

First of all, I don’t recommend this. I’ve used manual file management and automated tools, and I definitely recommend the automated tools. I’ve never lost any data because of the automated tools.

PDM really just takes file management best practice and automates it. So if you’re looking for an example for good file management techniques, figure out how the PDM tools do it, and copy that.

Secondly, there are as many different ways of implementing PDM tools as there are companies. Every company is going to have different needs. No matter what I say here, people are going to disagree with me. Some of them will have a valid basis for disagreeing, some are just afraid of what they don’t know or think they can’t control. My recommendations here will tend toward the conservative. Some places contend they don’t need model part numbers or model revisions. Some places contend they CANNOT use in-context. (These two claims may be related in many cases). I personally think that the only excuse for avoiding these things are fear and ignorance.

Third, the SolidWorks file management world is deterministic. Nothing supernatural ever happens to your data. In fact, everything is “knowable”. It’s even predictable. PDM automation wouldn’t be able to work if it wasn’t predictable. It definitely follows certain rules. You can in many cases fix file management mistakes, although it may require some creativity at times.

Fourth, I’m a firm believer that almost any rule can be broken, so you usually won’t hear me say things in the absolute, such as “Thou shalt not create in-context relationships”. Instead, I might say “Only create in-context relationships if you know what you’re doing enough to not blow them up unintentionally”.

With all of that said, I’m going to take the cheap way out and just copy/paste one chapter from my 2009 SolidWorks Administration Bible. This is Chapter 3, entitled Preparing Document Management. It was about 17 pages in the manuscript, but I’ve chopped it down a little here. The fundamentals for document management in SW haven’t really changed in the last 10 years, so some of the interface and references to old versions will seem outdated, but most of the information remains good. In fact, you could mostly use the same rules for Solid Edge. Tools like Fusion 360 and Onshape will be drastically different, however.

**By the way, this book is still available from Amazon as an ebook, if you’re interested. It looks like you can get used paperback version, but some people are gouging for them. Amazon Link.

***I used to check the reviews on my books from time to time, but I got out of the habit, mostly because it was never the good news I was hoping for. I have to say that the comments on the Administration book actually made me feel good that I had written that book. People on the internet are so often just interested in trying to look smart by tearing other people down, but these comments made me realize that the book was probably worth writing, and that there are some people left who know how to express positive feelings. Thanks to those folks. I know Mark Landsaat in particular comes around here from time to time. Really, thanks.

===============================================================

The interrelationships between part, assembly and drawing documents in SolidWorks need to be managed more carefully than just a system of flat files. SolidWorks and all 3D parametric modelers have some special needs. If you follow some simple rules, you can manage the files successfully.

However, taking a lot of shortcuts in the file management may leave you with a set of disassociated documents if you do not understand and follow the document management rules and handle files according to those rules.

If you or your company is new to SolidWorks, it is important to get your document management process figured out as early as you can. Making changes to an existing will become more painful the more entrenched the system is and the more changes you have to make. You have many important choices before you, and these choices are not easy to change later on if  you discover a flaw in your reasoning or execution. You really do have to understand the issues completely right up front and make good decisions right away that you will live with for the life of your document management system. While that statement may be somewhat overblown, you can actually make changes or adjustments, but changes to a system in use are something you should avoid if at all possible.

Naming conventions

File naming conventions is a topic that has spawned many quasi-religious arguments. You find strong opinions on all sides of this issue. The main arguments are for or against an intelligent part numbering system where portions of the part number signify options in the product.

My purpose here is not to declare a winner in this feud, but rather to give positive and negative arguments for each side. The issue is complex, and there certainly is no clear correct choice. When it comes right down to it, the choice that documentation people face here is how much do you trust your ability to create a system that anticipates all of your needs, including needs that don’t exist right now?

People who like automatic systems tend to go with the intelligent schemes. People who like to be absolutely positive that nothing bad will happen go for the sequential system.

Choosing between intelligent and sequential conventions

For the purposes of this book, I want to remain mostly neutral on the question of which technique is the best, because there are valid arguments on both sides. It might be more accurate to say that instead of remaining neutral, I will actually argue for and against both sides of the issue. You may start to think that I’m arguing against myself, and you’d be exactly right. My point here is to help you make a decision, but I’m not trying to influence you in  a particular direction.

I will say that regardless of which system you choose, it is probably prudent to have at least a portion of the part number to be sequential (non-intelligent, random), although I have an excellent example of a situation in which that piece of advice was not followed, yet the system is highly successful. The reason for requiring a section of a number to be sequential is to avoid duplication in a system that could possibly create duplicate part numbers for different parts. I do not dispute that there may be some value in intelligent part numbering, but I also think that any in any intelligent system, unless things are extraordinarily well defined, there is the possibility to duplicate part numbers.

Advantages of intelligent part numbering

The main advantages of intelligent part numbering are that you can always tell exactly what part you are talking about right from the part number, and that parts that are similar will have part numbers that are similar. Intelligent part numbering appeals to our need for order and our desire to classify things. It’s a very organized and thoroughly planned way of doing things.

Intelligent part numbers are often divided into sections, possibly using prefixes or suffixes set off from the main number by dashes or dots. For example, an intelligent part number might look like this:

 

The prefix in this case could stand for a document type such as manufacturing drawing, inspection drawing, assembly instructions, or if the part number signifies a part rather than a drawing, it could stand for some classification of the actual part, such as casting, machined part, circuit board, and so on.

Note: It is an important distinction between using part numbers for parts and/or documents. With intelligent part numbers, you can tell the difference between numbers intended for drawings of the same part that have different functions and the part itself.

The main number can also have significance, and you usually need a key to decipher its meaning. For example, within the prefix say 08 which signifies circuit boards, the first two numbers (shown as 12) mean different types of circuit boards, 01 for single layer, 02 for double layer, 03 for ceramic, 04 for FR-4, 06 for flex circuits, and so on. The next three numbers might apply to the project number.

Suffixes can be used or not used as needed. In the case of the circuit board example, the suffixes might signify its input or output voltage, types of connectors or other characteristics of significance where options exist.

Examples of significant part numbers are easy to find. If you go to a catalog house, part numbers for many catalog parts are laid out as intelligent part numbers with some sort of an identification key for ordering. Catalogs might have many different intelligent schemes, because a single scheme as shown in Figure 3.1 would not be enough to apply to every part in the catalog inventory.

An example of a highly successful intelligent part numbering system is automobile tires. In fact, tires have a long established intelligent part numbering system that works across many vendors around the world. You can go to different tire vendors, give them the part number from a different vendor, and they know exactly what you are talking about. This system has held up for years, and works seemingly flawlessly. All of the numbers or letters have some sort of significance.

Figure 3.2 shows the classification system used on tires, which serves as part numbers. The number P215/65R15 is recognizable around the world regardless of vendor. Notice also that as successful as it is, this part numbering scheme has at least one glaring error that engineers would never tolerate – mixed units (inches for rim diameter and millimeters for width).

This image is from the Wikipedia.org entry on Tire Code

So intelligent part numbering is really trying to classify the part with the part number. When the system works, it makes identifying parts very easy.

Disadvantages of intelligent part numbering

Because intelligent part numbering is really just building a classification system, the success of an intelligent part numbering system depends heavily on the number of items being classified remaining relatively static, and very easy to identify.

The Dewey Decimal System

Another example of an even older intelligent part numbering system is the Dewey Decimal System. In this system, there are ten top level classes, each broken down into dozens of subdivisions. This number is then followed by a Cutter number which is composed of a composite of the author’s name and a number from a chart of names, along with potential entries for year of publication, edition number, copy number, and a number of other things. The Cutter numbers are mainly to avoid duplicates in the classification system.

I suppose it is no wonder that students find the Dewey Decimal System such a chore to learn, and industry has not been lining up to copy it. While the Dewey Decimal System is still in use, I consider it to be a good example of what can go wrong with an intelligent numbering system. It leaves a lot open to interpretation such that a book may have two different DDS numbers from different libraries. The rules are so complex that it’s a difficult system to follow.

The system has worked for over 125 years, but it has gone through 20+ revisions in that time, and still retains many faults. But it does work. This is a common comment with intelligent numbering systems. The systems have many faults, but they do work. It is left up to you to determine if what it buys you (a flawed classification system) is worth the price you pay for it (it makes duplicate part numbers, but doesn’t guarantee that two people would assign the same part number to the same item). You must also determine if it is better than the alternative, sequential part numbers, where there is no classification at all other than the order in which numbers were assigned to the items.

The Circuit Board example

Let’s go back to the circuit board example and see where we can find problems with that intelligent system.

First, what happens if the company designs a new radiator cap for an automobile that has circuitry built into the injection molded cap. How do you classify this new part? Is it a circuit board, because it uses that design and manufacturing process, or is it an injection molded part, because it also uses that process? Or what if your company had a classification for inseparable subassembly? It is also that.

The big problem here is that depending on what kinds of parts your company has to deal with, you may be in a situation where change is not predictable, and be clear that the one thing that begins to bring this intelligent part numbering system to its knees is change, especially when parts start to cross classifications.

Another disadvantage is that for different types of parts you have to have a different classification system. This means that you do not have only one numbering system, but many.

If you make tires, you may be in luck, but other types of manufacturers are not so lucky. The example of the tires shows that even flawed classification systems can be highly successful, if by success you mean unambiguous and widely used. But the circuit board example shows that not all products are easy to classify, and not all products will see the same sort of success as tires.

Advantages and disadvantages of sequential part numbers

On the surface of things, sequential part numbers do not seem to have any advantages whatsoever because they do not give you any information unless you happen to remember that particular part number. Sequential part numbers are usually just the next in line number in a database, or in days gone by they used to come from a log book, and just took out the next number for a new part.

It turns out that sequential numbers do have several advantages. The main advantage is that there is no way to get duplicate numbers. The idea that each item should have a unique identifier is one of the cardinal rules of document management, and it turns out to be one of the rules that fully intelligent part numbering can easily transgress.

When people make arguments in favor of sequential part numbers (also called non-intelligent numbers), another of the advantages they cite is that there is no data associated with the part number. This is an advantage because you are not duplicating the function of the part number. Is the part number meant to classify the part or simply identify the part? The data, or significance that would be conveyed through the intelligent number must be attached to the part in some other way. Proponents of sequential numbering claim that the part number is only for identification, and that classification comes through the metadata (non geometrical text data) attached to the part through a database or in SolidWorks through the custom properties functionality.

If you use sequential part numbers, the bottom line is that you have to have some mechanism for relating the description of the article to the part number. This usually means a PDM, MRP or ERP system. These database-driven systems always have a way to connect what is called metadata to the part number. This enables text searches to find actual human readable text of the metadata rather than cryptic number strings of the sequential part number.

Obviously, this system does not depend on the types of products a company has to document. You can apply sequential numbers to absolutely anything without restrictions. Intelligent part numbers only work for rather simplified classes of products.

Comparing part numbers, document numbers and file names

In the discussion about part numbers, we didn’t really discuss file names, although I alluded to the idea that numbers that identify documents may or may not be the same as numbers that identify actual physical parts. This may get a little confusing, so stay with me here.

Let’s say you have a Bill of Materials (BOM), and some poor fellow has to go put together this list of items from the BOM. So our fellow takes the BOM and goes out to the warehouse. The first item on the list is 12345, and it has a description of Transmission Housing Casting. In the warehouse, there is no such part, but when he looks it up on MRP (manufacturing resource planning system), Joe finds that 12345 is a drawing of the casting, and that there is also a drawing for the casting die, a drawing for the secondary machining operations for the casting, as well as a machining fixture, machining fixture drawing, shipping crate, a shipping crate drawing, a transmission assembly instructions document and a transmission assembly drawing. Not only does that number bring up all of those things, but it also lists part numbers for physical parts, electronic files for the drawings and the models the drawings were made from.

If you are new to document management, this is something you will need to confront at one point or another. When creating part numbers, you have to be explicit about what that number stands for, physical part, paper drawing or electronic document. What is our warehouse fellow supposed to collect for his BOM list? An aluminum casting? A paper drawing? An electronic file?

Creating a hybrid intelligent-sequential system

If the part number 12345 stands for the Transmission Housing Casting, you may or may not want all documents related to that part to have the same number. A prefix accomplished this task in the circuit board example, but it could also be done with a suffix.

12345-01 – physical part ready for assembly

12345-02 – part specification or drawing

12345-03 – secondary operations drawing

12345-04 – raw material part (as cast) in need of secondary operations

12345-05 – 3D CAD model electronic file

This system is a hybrid between a sequential main number and an intelligent suffix. It has broken down the intelligence to a level where it is controllable and useful.

You could use a strictly sequential scheme where it might look like this:

12345 – physical part ready for assembly

12346 – part specification or drawing

12347 – secondary operations drawing

12348 – raw material part (as cast) in need of secondary operations

12349 – 3D CAD model electronic file

This system is also perfectly acceptable, but it does not immediately convey what type of item each part number is. It seems easy to be attracted to the hybrid system. Taken in smaller doses, the intelligence seems like a good thing to have, but it doesn’t seem to be able to handle the very top level of part number organization unless you have a very controlled system like the tires.

You may think that this is all starting to get rather complicated, because for this one transmission housing, we have several types of items to keep track of. We have the physical part in a couple of different states of manufacture, several different 2D electronic drawings, and the 3D models. Is it really necessary to keep track of each of these? Yes, it is. You have a manufacturing process, and need to keep track of Work In Progress parts, along with finished parts and completed subassemblies, tested, untested, and so on. You need to think in part numbers and document numbers, and where the parts are in the manufacturing process.

Adding file names to the mix

In SolidWorks, when you put a part or an assembly onto a drawing, the drawing inherits the name of the model. This doesn’t necessarily carry over to document management, but it can if you want it to. In SolidWorks you can have a part named 12345.SLDPRT along with a drawing called 12345.SLDDRW and an assembly named 12345.SLDASM.

The one cardinal rule in SolidWorks document management is that you can’t have duplicate file names. Your document control process, whether manual through folders in a network drive or automated through a PDM system needs to reflect this. Windows does not allow you to put two files with the same name into the same folder. PDM systems that allow multiple files with the same names do it because they identify the files through database identifiers, not necessarily because it’s a good idea.

The case of needing unique file names is the same as needing unique part or document numbers above. If you get away from the idea of intelligent part numbers, then all of these names and numbers are used for the exclusive purpose of identifying the file, part or document. It makes sense that the part or document number should be used as the file name because the file name has the same purpose as the part number – just to identify the file. It doesn’t remove the need to distinguish electronic files from physical parts, but it does guarantee that you do not get things confused. I would also recommend using some sort of a prefix or suffix to be able to quickly identify different types of numbers.

Using a descriptive naming convention

The discussion about descriptive names versus the more cryptic numerical names for SolidWorks file names often brings up as heated a debate as the sequential versus intelligent part number question. By “descriptive names” I mean giving a human readable name in plain language SolidWorks file a name like “cover.SLDPRT”. This could also apply to more specifically descriptive names like “Motorola Transformer Cast Cover.SLDPRT”. You probably see a lot of people with this kind of name for their SolidWorks parts, but I want to discourage you from adopting a convention like this for anything but concept design work. If it has to be documented and managed, you should assign a proper name to it.

Some people reason that the file name should be human readable text to help you identify the part just by sorting alphabetically and looking for it in Windows Explorer. This seems like a reasonable assertion until you look into the issue a little deeper. The requirement isn’t only to be able to identify the part visually, but to be able to identify the part uniquely. This issue will keep returning as long as you try to use the file name to add information other than a unique identifier for the document.

Using metadata

By now I’m hoping you see the need for unique file names. The case is not yet complete, however. If you can’t put significance in the part number, and you can’t use descriptive plain language names, and are stuck with cryptic sequential numbers for file names, how will you identify parts aside from memorizing the numbers?

The obvious answer is to use metadata. Metadata includes any sort of descriptive text in any category you might choose that is either kept inside the file as custom property data or associated with the file through a database. So if you have a description for the part or document, put it in a field called “Description”. In SolidWorks documents this is best done as a custom property. Custom Property data can be searched in Windows Explorer, even if you are doing just manual document management, but it is not as convenient or as powerful as if you are using a true PDM system

Figure 3.2 shows SolidWorks custom property for Description showing up in the tool tip balloon.

The ultimate answer that this line of questioning is leading to is that for almost any SolidWorks user,  whether small or large, documents should be managed in a PDM system. PDM does not have to be expensive or difficult to install or maintain, but it does answer all the questions raised in this chapter.

The way PDM answers all the difficulties is by enforcing unique document names used to uniquely identify documents, and using metadata to describe or categorize the document. Typical metadata (custom properties) include description, material, finish, supplier, color, customer, voltage, drawn by, approved by, date approved, and so on. Any way you want to classify the part or document where a property has a value can be used to identify the document through search functionality. It is more than just convenient, more than just a reasonable replacement for Windows Explorer searches, you will find it far more useful as well.

In addition to simple searches, you can also create BOM type data from PDM, as well as where used reports, or a number of other uses.

The last few chapters of this book are dedicated to Workgroup PDM, which is the simple PDM tool included with all but the base level of SolidWorks. Workgroup PDM is easy to install and set up, and handles your SolidWorks and other types of data.

Another way to add metadata to SolidWorks parts, assemblies and drawings is to use the Tags function. Tags function is found in the lower right corner of the SolidWorks window, with the small yellow icon that looks like a tag, shown in Figure 3.3.

Tags can be used to tag specific parts in an assembly or features within a part. If Windows Search has indexed your files, then SolidWorks Explorer and SolidWorks Search can be used to search for properties as well as tags. You can think of tags as being like properties, except the tag only has the value without having the property. You could also think of Tags as keywords that are associated with a part or feature.

A deeper description of how to use SolidWorks Explorer for manual file management is later in this chapter.

One piece of good advice that you can count on is that if you already have a file naming scheme and it is not causing problems, stick with it. Changing part numbering schemes will probably cause more problems than simply working even with a flawed scheme. It is likely that any system you come up with is going to have a flaw of some sort in it, and replacing flaws you know with flaws you have not yet discovered is probably not a move forward.

Organizing files

The way that you would organize SolidWorks documents is similar to the way you would do it for data from other 3D modelers such as Inventor, Solid Edge or Pro/ENGINEER. It is widely different from how you would organize 2D design data, however. 2D design data is typically flat files without relationships or hierarchy, much like organizing images or music files. Typically this type of file is just put into folders that can be browsed easily or searched with Windows search functionality.

Folder structures for flat files can take a number of forms. I’ve seen folders named by part number range, by the department that uses or creates the data, by customer, by file type, and other sorting methods. If you have an effective search tool, organization doesn’t matter much, although some people prefer to browse to files rather than use search.

Figure 3.4 shows a potential organization scheme with the top level organization being by department.

How you organize SolidWorks files is very dependent upon what type of data you are creating and how it is used. Many valid organization schemes exist, the main task is to identify one that works best for your business practices and minimizes the drawbacks.

An example of widely different needs for organizing files would be a company that makes a product of all custom parts, where all or most parts in the assembly are unique to that product, and are not shared with other products. You might organize the files for that product all in a single folder. Contrast the way you would store SolidWorks files for that as compared with a company that makes every product from standard purchased items or parts or subassemblies that are shared with other products the company makes. Those files you would probably organize in folders by the type of part it is, standard hardware, springs, wheels, frame, cover, motor, and so on. There is no one recommendation I can make that will fit every situation.

Some companies do only the design, and send the design out to be manufactured. Some companies do only manufacturing, without designing finished products. Some companies do both design and manufacturing. Data for products that are shipped to customers should probably be separated from data for tooling , fixturing and manufacturing reference. Some documentation may even be sent directly to the customer, such as installation instructions, exploded view parts lists or troubleshooting guides.

It might be considered a best practice to use the classifications of different types of documentation that you create as the top level divisions. This would mean the top level folders would be Design, Manufacturing, Quality and Service. You would not typically include personnel, sales, facilities or financial records with your design data, but I have seen companies include all official documentation such as Human Resources manuals, policy documents, forms, and so on in the documentation system. These documents are or should be revision controlled, with controlled access, and this is exactly what a documentation system provides. You as CAD Administrator may not control those documents, buy you would control the system that enables access.

Creating libraries

Managing libraries and reused components are cases that bring up several interesting questions. Some companies like to use project or product names/numbers in their folder organization scheme and/or part numbers, but this scheme does not work well with library parts. Often libraries contain parts that have multiple sizes of similar parts, and this arrangement works well with a semi-intelligent numbering scheme, where the main part number is a sequential number, and then an intelligent suffix indentifies the size or other options for a part. You need to make tabulated drawings for this type of data, showing a break down of the intelligence in the scheme, such as shown in Figure 3.5.

The scheme shown in Figure 3.5 shows the sequential part number in the front, 54186 selected sequentially from a database to signify Pan Head Machine Screw, a “dash” number signifying  library type part in this case, and a suffix that describes the characteristics of the screw.

This system works well for this particular part, but what about when you start using flat head screws. You have 82 and 100 degree heads, and so you will need another classification for that.

When you establish the format for numbers like this, it is critical to get the numbers in the correct order. The main issue you need to deal with here is alphabetization. When you sort the numbers, you want them to show up in a reasonable order. In this case, the numbers will show up in the order of the sequential number. That doesn’t make good sense, because the sequential number might as well be random, so sorting by that number doesn’t give you any additional information. Possibly moving the “dash” number to the front would group all hardware (-0-) together. So making the “dash” number a prefix might be a better choice in this case.

One of the characteristics of a library is that it can be used across departments, and in different types of documentation. Engineering can use the screws to put together product that is shipped to the customer, and manufacturing can use screws to design fixturing to assemble the product.

In short, libraries are a great way to reuse data. Toolbox creates a bit of an administration headache, but you can get it to work. How well it will work for you depends really on what you want to get out of it, and how you plan to use it. More on this topic comes later in this book.

Avoiding common mistakes

The biggest mistake that companies make when setting up an organization scheme is to make it too complicated. Browsing is out. Search is in. When you perform a search, the only reason you would want to limit the search would be because the complete search takes too long or produces too many results. So unless you have enough data to slow down your search mechanism significantly, there is actually little reason to organize your folders at all. It may seem foreign to you to just throw all the data into a big folder, but when you use search rather than browsing, that actually becomes an option.

If you feel that you do have to organize for browsing, try to keep the hierarchy to a minimum. Needing to browse more than 4 levels deep is probably unnecessary. Three levels are sufficient for most purposes. If you have to think about the options for more than a few seconds, your scheme is probably too complicated. Anyone browsing to data is going to rely on quick decisions.

Suggesting options

Some options for top level organization would be “By Department” example laid out earlier. Remember that this included Design, Manufacturing, Quality and Service. Within each of those top level folders, you might consider each product or project to have its own folder, with a folder for items that are common to all (for example hardware libraries), and possibly a folder which belongs to no project (such as standard forms, or service repair logs). Within the product/project folders it may or may not make sense to break it down any further than that.

Of course the entire organization structure could also go exactly the opposite way, where the product/project folders are at the top level, and then the departmental breakdowns would be inside those folders. One of the determining factors to help you choose between the available options might be security. Does your company policy require that you establish permissions for different levels of access? Are these permissions easier to assign and maintain if they are done by department or by project?

Breaking references

I have seen some beginning SolidWorks users try to organize folders in Windows Explorer by SolidWorks document type. After completing a design, they took the files, just like they did their AutoCAD files, and moved SolidWorks parts to one folder, organized by part number, assemblies to a similar area, and drawings to another area altogether. There was a little surprise when assemblies and drawings were always broken after the official release of the documents.

Moving files by using Windows Explorer breaks relationships between files because although you moved the files, you never told SolidWorks that the files were moved or where they were moved to. The proper way to do this is to use either the Save As functionality within SolidWorks itself, or to use SolidWorks Explorer. The various types of relationships are described in the next section of this chapter.

In order to avoid the common mistake of breaking relationships by moving files around, it may be best to keep groups of files together when they are together naturally. If you create a set of files together, then they are together naturally. If you make all of the parts to be put together into an assembly, then those parts should probably remain in the same folder.

There are some exceptions to this, such as parts that will be reused in other assemblies, including library parts.

Understanding SolidWorks document relationships

Many people get overwhelmed by managing the different types of relationships that can exist between SolidWorks documents. In reality, the relationships are not all that complex. If you are not already familiar with them, here is a bit of a primer.

Part files are the bottom of the food chain in SolidWorks. This is where it all begins. Parts have the extension of *.SLDPRT. It may be capitalized or lower case, depending on the template the file was created from, but the standard templates from SolidWorks use upper case.

Part files may be put into assemblies or drawings. When that happens, the assembly or drawing references the part, and must be able to find the part at all times.

Assembly documents may also be put into assembly documents, such that you would have a subassembly and upper level assembly. Each assembly file has its own name, and the assembly file extension is *.SLDASM. Assembly files may in turn be put onto a drawing.

Drawing documents are the top of the SolidWorks document food chain. Nothing references a drawing, but a drawing always (or almost always) references something else. Parts and assemblies may be referenced by the drawing, and the drawing has to know where the part and assembly files are at any given time. There are small exceptions to all of this with functionality called detached drawings, lightweight, or Speed Pak, but ignore those for now.

When you open an assembly that references a part, SolidWorks looks for the part in specific locations. If you assume it first looks for the part in the last location where the part was saved when the assembly was open, you would be wrong. That is actually the 2nd or 3rd place where it looks, depending on settings.

Note: Ok, this should scare you a little bit. SolidWorks looks for referenced documents in 1 or 2 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 not to have unique file names, and also to not have multiple versions of the same part with the same name 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.

The fact is that SolidWorks can look for any referenced document in a total 13 different places. This is why it is so imperative that you pay attention to the file management rules in SolidWorks and do not move SolidWorks files without telling the referencing file where the referenced file has gone to.

Tip: For the actual list of all 13 locations where SolidWorks looks for referenced files, look in the Help under Search file locations for external references.

As a hint, the very first place where SolidWorks looks is to see if a file of the name the referencing document is looking for is already open. If it is, you get that document whether it is the one you are looking for or not. Read that again. This needs to sink in because it is very important.

So, if you have an assembly open, and that assembly has a part called Cover.SLDPRT in it. And then you open another assembly, which also has a part called Cover.SLDPRT, but it is a different part from a different folder, SolidWorks is going to put the Cover.SLDPRT from the first assembly into the second assembly. It will also give you a warning that the part doesn’t belong in the second assembly.

This is why unique file names are so important, in fact mandatory. This is why descriptive names and intelligent names are discouraged. Neither descriptive nor intelligent names can guarantee uniqueness unless they also contain a portion of the name that is also sequential, and taken from a single list of numbers (database).

Organizing subassemblies

In SolidWorks, many reasons exist why someone might want to make a subassembly. Subassemblies can be created for performance (speed of software operation) reasons, or maybe when the product is assembled, one set of parts is put together as a group. You might create a subassembly to facilitate patterning or motion. You might make a subassembly to assist with an exploded view on a drawing, or possibly to create a detailed view of a purchased component that has parts that must be removed in order for the component to be installed.

Of the many reasons that exist for you to make subassemblies in SolidWorks, few of them might actually result in a drawing document. Many assemblies are made for modeling reasons rather than documentation reasons. This practice is something you need to be aware of at your company. This concept comes up later in this chapter when the topic of making revisions or changing part numbers of subassemblies is approached and how that affects other documentation.

Using SolidWorks Explorer and SolidWorks or Windows Search

SolidWorks Explorer doubles as the Workgroup PDM standalone client interface as well as the no cost simple file management tool for SolidWorks data. Even if you have another full featured PDM solution, you can still use SolidWorks Explorer to copy, rename or replace files outside of the vault. You can access SolidWorks Explorer through the Start menu, Programs, SolidWorks. This may initially bring up only a small search box, but you can also expand this to show a File Explorer interface for browsing, and a larger display interface.

You should only expect SolidWorks Explorer to work well if you have used Windows Search to index all of the drives or folders you want to search. Otherwise, it will miss some items such as tags and custom properties. To use SolidWorks Explorer to search for files, enter the name of the file in the box at the upper left of the expanded interface. This will bring up a Results panel immediately under the search box.

Figure 3.7 shows the partially expanded state of SolidWorks Explorer, along with some additional search narrowing options. The drop-down arrow in the search box enables you to select from recent searches or a set of commonly used keywords. When you select a document to view, the box grows larger and enables you to view graphics and other types of data.

You may also recognize some of the functionality in SolidWorks Explorer as regular SolidWorks functionality. The SolidWorks Search box also exists in the upper right of the SolidWorks window, along with the File Explorer interface, so much of this functionality is also available from within the SolidWorks interface itself.

In the chapters of Part 4 of this book, we will return to SolidWorks Explorer in the guise of the Workgroup PDM standalone client interface.

SolidWorks Explorer was originally meant as a standalone interface to do some of the basic file management tasks that you would other wise need SolidWorks to do. You can use it to rename, replace, move, copy, Pack and Go, view, add custom properties and tags, and so on

Controlling revisions

This section of the chapter has to start with a vocabulary and concepts lesson. The distinctions between the concepts involved are often too subtle for words, but never the less important in the world of document management.

If you are new to document control, and setting up a new document control system, get used to it, a lot of decisions must be made. Even in the light of the controversial topics we have already discussed in this chapter, Revision control can be one of the most contentious of them all. Novices in this area need to listen to all the arguments carefully before taking sides.

First of all, you need to be able to articulate what the difference between a revision of a part and a change that requires an entirely new part number. The simple answer is that if you can replace the old part with the new part, and it doesn’t change the fit, form or function of the product, you’ve got yourself a revision. If it is not a drop in replacement, you should assign a new part number. This distinction is hammered religiously into new documentation recruits, and believe me, you will get it wrong as often as you get it right, even experienced professionals get this one wrong on a regular basis. You really need to be careful with the distinction between new part numbers and new revisions.

Beyond that is the distinction between revisions and versions. This definition may vary from company to company, but versions are usually defined as incrementally changed iterations between revisions. So if you have Revision A and Revision B, you might also have Revision A.1, where the *.1 is the first version between A and B. With those definitions out of the way, let’s move on to talk about revision schemes.

Revisioning schemes

Again with revision schemes you should not expect any straight answers to your questions. As many revision schemes exist as companies that have set them up. Every company has different needs, and everyone who works at these companies has an opinion about how the revision scheme should work.

The interesting part comes when you ask people at a company that already has a revision scheme set up to describe that scheme, it will be rare to get any two people to agree on what it is that they are currently doing. If you are starting fresh, you are lucky, because you can train people right from the start.

An example of a revision scheme is that development revisions go from 1 to 100 or as necessary. Production revisions go from A to Z, leaving out O, I, U, V and Z. If you run out of letters, revisions go AA -ZZ with the same exceptions. Intermediate versions are for engineering and quality use only, not for production, and will be designated as A.1, A.2, A.3 and so on.

In the chapters on Workgroup PDM we will revisit revision schemes with a slightly different spin. We will be concerned with making revision schemes work within the limitations of the Workgroup PDM software. PDM software automates revisioning functionality, and the first casualty of automation is usually flexibility, so you may not be able to match a company’s existing scheme 100%, you may have to make some compromises here and there.

In the end, your revision scheme again should be simple, and work for your business. You don’t get extra points for creating something complex or clever. It needs to work for everyone all the time.

Revising models versus revising documents

One of the issues you must come to grips with is the difference between documents and models. Beyond that, the difference between models and documents in terms of revision handling is important.

Contemplate this situation for example: You have a SolidWorks part and a drawing of the SolidWorks part. The first question you must answer is if these two files should always have the same revision level. Think about that one for a minute before you answer. Can you ever make changes to a SolidWorks part that would not affect the SolidWorks drawing? Might it ever make sense for a model to be at Rev B while the drawing for that part is as Rev A?

I have seen companies try to make model and drawing revisions match, and I do not think I have ever seen a successful implementation of this concept. You either avoid making changes that would be nice to make or you wind up doing too much work. I think models and documents don’t need to have identical revisions.

As an example of why a model and a drawing do not need to have the same revision, first think of a model that goes through multiple changes before the drawing is ever made. The part might be at Rev C before the drawing is created, and the drawing must be released at Rev A. Another example is that some non-geometrical change happens to the model, which requires that it be up-revved, but does not require a change to the drawing. The change might be a color, or modeling changes to remove a sketch error, or a change to the configurations used in the part that do not effect the drawing. You might choose to change custom property information which affects the assembly BOM, but not the part drawing.

Most people start by thinking that intuitively it is best to have the model and the drawing reflect one another completely, but by the time they have reasoned out a few scenarios, most feel convinced that they should be separate.

Using different revisioning schemes for models and drawings

You may decide after reading all of this and trying to apply different concepts to scenarios you have found yourself in throughout your career that you should apply a different revision scheme to models and drawings. Models are really supporting information, except in the case where a CNC operator programs tool paths from an existing file.

In particular, it might be a good idea if you use a development revision scheme for models and a production revision scheme for drawings. Will models such as SolidWorks 3D parts and assemblies every actually have a “released” status in your company’s documentation scheme? Issues like this are why the Documentation Manager and the Cad Administrator are often the same people, and in any case need to work closely together. For your company to put together a definitive answer on this question may require some open-minded discussion between multiple parties. I don’t think it is the kind of question that has a single correct answer.

Storing revisions

If you are manually managing revisions of SolidWorks documents, this is where your nightmare actually begins. Revision management is why most parametric 3D modelers like SolidWorks push automating document management through PDM applications so much. The actual work of manually storing and managing revisions in SolidWorks can be a nightmare, and is very error prone. That said, it is actually possible to do things correctly, but the work is tedious enough that you will wish for a simple file manager by the time you understand how it all actually works.

Storing revisions will cause you to break several best practice suggestions. There isn’t really a way around that if you want to store old revisions and you don’t want to use a PDM system.

Tracking revisions of models and documents

I don’t think anyone would argue about the necessity of tracking revisions to drawings, but some times companies debate the issue of whether it also makes sense to track revisions of the models (parts and assemblies). It is certainly a recommended “best practice” for all companies to manage all data, but it also adds very significantly to the work load if you are trying to manage revisions manually.

If your business uses primarily paper documents or electronic dwg/dxf or pdf documents to have products manufactured, then your SolidWorks drawing documents are the primary document type, and model data is just reference. I don’t actually recommend not managing model data, because it is incomplete and a sloppy way to work. But if you are managing files manually anyway, it may be the difference between absolutely nothing and something. You might think this is a valuable shortcut, but I warn against it. Consider as an alternative that you could save out a DWG file at the end, and just manage the DWG file. This is also poor practice, but better than trying to just manage the SolidWorks drawings without the models. The reason managing translated DWG files is considered bad practice is that all of the associativity of the SolidWorks drawing is simply discarded when you move to the DWG format. Also, translating out to DWG is a method often employed in failed SolidWorks implementations, where users are too busy leaning on legacy tools to focus on moving forward. Mixed 2D-3D CAD environments are certainly valid, but typically data created in one system stays in that system.

Most companies will decide that they need to manage model revisions as well as drawings. Part of the reason for that is that the drawings without the models aren’t worth much. Also, if a model changes, your drawing changes, so the only complete way to control a drawing in SolidWorks is to also control the associated model.

Changing revision levels for documents

Let’s say you have an assembly at Rev A, all the parts are initially at Rev A, and the assembly drawing and all part drawings are also at Rev A. Then you make a change to one of the parts that requires it to go to Rev B. Does your assembly also go to Rev B at this point? What about your part drawing and assembly drawing?

Your assembly should not change revision level if the only change is the revision level of a part. An assembly revision-worthy change to a SolidWorks assembly document would be removing or adding a part, changing an assembly feature, or possibly changing mates.

Also, recall the “fit, form or function” rule to determine if a change to an assembly would require the assembly to get an entirely new part number altogether. Of course that depends on if your assembly scheme actually lines up with any assembly documents.

Updating stored revisions

When moving from one version of SolidWorks to another, say from SolidWorks 2009 to SolidWorks 2010, SolidWorks technical people often recommend for CAD administrators to use the SolidWorks Task Scheduler in order to save all of your files in the new version format. Part of the reason for this is so that large assemblies will work faster because they do not have to update all of the files on the fly and write them to memory. On the surface of things, this is a good idea. But is it really a good idea?

If SolidWorks moved from one version to another without introducing problems with files, this would be a great idea. But the truth is that often SolidWorks introduces small changes in how mates are evaluated, or how a spline is calculated or the conditions used in a Boundary surface affect the final shape. Because of things like this, moving from one version of SolidWorks to another is rarely an uneventful task, especially for assemblies and complex parts.

SolidWorks offers tools that will even go into the PDM vault and change files directly inside the vault without changing revisions. To me, this is a cardinal sin from a document control point of view. If a file is changed in any way, you should change the revision. Updating a file between SolidWorks versions has the potential to change geometry in unpredictable ways. I think this should be done on a case-by-case basis so that you can catch the problems as they occur.

You will need to weigh for yourself how you want to manage this issue. If you have large assemblies of mostly simple parts, the affects on your models may not be that great and the time savings may be the driving factor, but if you have drawings with a lot of annotations or various view types or complex shapes with lofted splines, fit and boundary surfaces and so on, your data may be critical enough to check it on a per document basis.

Putting revision levels in file names or metadata

Thinking about how to Handle revision levels in SolidWorks documents when manually managing files brings you to two conclusions, both of which are considered poor practice.

If you have ever worked with AutoCAD or another 2D package, and you were responsible in any way for controlling revisions in that package, you probably are used to putting the revision level into the file name by appending “Rev A” onto the file name just before the extension.

In SolidWorks, doing this can work, but it may also cause files to become disassociated. When you use a PDM product with SolidWorks, the revision levels are kept in a custom property inside the SolidWorks file and/or inside the PDM application’s database. Remember that changing a file name can break the link between a document and its referencing document.

If you place a revision label inside a part (in a custom property), you cannot see it outside the part except with SolidWorks Explorer or a PDM application. If you are manually managing files, that’s pretty inconvenient. So how do you manually manage files and not put revision levels in file names?

Revision levels in file names

If you place the revision levels in file names, you can break links between parts. If you have large amounts of data, managing this manually becomes very tedious, and you will have to use a program like SolidWorks Explorer (to do mass replace of “Rev A” with “Rev B”). Of course something like this is also error prone. If you have relatively few documents to work on, this might be relatively painless. I have seen people put dates in file names and used that as a revision level when no formal revisioning scheme existed. I have used dates in names when my project consisted of a single part. When dealing with a single part, there are no references to break.

Revision levels in folder names

An alternative to revision levels in file names might be revision levels in folder names. Again, if the files inside the folder are referenced by files outside the folder, you may also break associativity. Another problem with this is that it is not a requirement for all of the parts and subassemblies to have the same revision level, so parts could be scattered all over the place. On the other hand, you might just put the assembly revision level in the folder name and copy the entire folder to make a new revision level, but that does nothing for managing part revisions.

The main fault of this way of handling revisions is that it creates multiple copies of files with the same name. Remember the 13 paths SolidWorks looks through to find referenced files? Revision levels in file names are bad because you can break links to assemblies and drawings, but at least the errors are obvious.  Revision levels in folder names is even worse because the error of picking a part from one of the obsolete folders  may look right, but may not be immediately obvious that it is a mistake.

Mixing methods

Ironically, the best of two different bad ways of doing something may be to combine the bad methods. This may also be complicated and not immediately obvious, but it will help with the next topic in this chapter, and it will solve the problems mentioned previously.

If you leave the current revision files without revisions in their names, and only add revisions to the file names after a revision becomes an “old” revision, I think this is the most reliable method for manually managing files. It breaks the links when revisions become outdated, and maintains the links for latest revisions. Inside of SolidWorks, the way you would save out the old file and go forward with the latest revision would be to use File @@==> Save As with the Save As Copy option, renaming the copy to include the old revision level. This method is not completely intuitive, because if the latest revision is C, you are saving the file with a revision of B.

For example, the latest revision files would be 12345.SLDASM, which contains the parts 12346.SLDPRT and 12347.SLDPRT. These files might be Rev A, Rev B and Rev C respectively. The old revisions for the files could exist in the same folder or a different folder, and would be named 12346 Rev A.SLDPRT, 12347 Rev A.SLDPRT and 12347 Rev B.SLDPRT.

Any manual method is going to rely on a group of people remembering to do the right thing every time, and so will be prone to a lot of errors. This is the only method I have become aware of that actively leaves the valuable SolidWorks functionality in tact and minimizes potential for human error.

Retrieving old revisions

In any document control process, you have to be able to retrieve old versions of files and documents. If your company has a service division that repairs old product, accessing old versions of documentation is essential. If piecing back together an old SolidWorks assembly is part of that process, the “mixing methods” technique would allow you to do that fairly easily.

The first thing you would have to do would be to find a BOM that shows the revision levels for all of the parts at a given rev of the assembly. Then pull all of those documents, and remove the “Rev X” part from the file name.

To retrieve an assembly along with parts from the “revision levels in folder names” method, you would just pull together the correct files from the correct folders. No renaming would be necessary.

To retrieve data using the “Revision levels in file names” method, you would need to find the correct assembly, and then the assembly should automatically find the correct parts.

You should also be aware that the likelihood of an error with any of these methods is pretty high. The truth is that any technique for manually managing electronic files is sure to be error prone.

Using configurations to store revisions

Another issue that may initially seem intuitively correct is to use configurations to store revisions. I have seen people do this and even claim that it works, but I do not believe that there is any way that using configurations can offer the same type of certainty that you can go back to an old revision and get the data you want.

The problem is that in real revision level changes, things get deleted, and things get changed in such a way that you cannot account for the change with a configuration. Many changes to features are configurable, but some are not, and many non-dimension changes in sketches are not configurable.

In order for this scheme to work, you would have to limit your changes to dimensional changes that can be configured (remember that some dimensions used as parameters in some PropertyManagers cannot be accessed by configurations, such as the values to drive a helix. Hole Wizard holes are only recently configurable (2009).

Beyond those arguments against this method, if you ever wanted to use configurations for any of the functionality for which they were intended, you wouldn’t be able to because the configurations would already be commandeered by the revision method.

Again, this is an idea that I don’t believe has any real application in real usage.