Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations GregLocock on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

What are some good SW revision control methods? 1

Status
Not open for further replies.

sheetmetalfan

Mechanical
Jan 23, 2003
1
Here is the problem:

I have typically a part with the file name "bracket_rev_b". Now the part gets revised. If the Solidworks file name is changed to be "bracket_rev_c", then I have to do all the steps to make sure that all assemblies where the part is referenced, are dealt with.

Is there a simple way to control electronic revisions, so that when the part gets sent to a fabricator, they can track it?
 
Replies continue below

Recommended for you

SW, by itself, does not have a way for revision control and tracking. You should have a PDM software to do that (like PDMWorks, an option software for SW).

If you don't want or can't buy a PDM software, you must have some turn arrounds to garantee the access to latest revisions. That's what I do:

- In one public folder, I give access only to the docs. with the latest revisions. I don't mix different revisions of docs. In fact, I allways discard the earlier revisions. I garantee to all departments that the file or drawing they are accessing is the latest approved revision;

- The revison state is identified not by the file name (the file name remains unchanged), but by custom properties. For example, for a doc. with rev. A, I have the custom property rev_A = "X"; for a doc. with rev. C, I have the custom properties rev_A = "X", rev_B = "X", rev_C = "X".

- Revison tracking: associated with each revision I have another custom property that informs what the revision was about. Example rev_A_modifications = "some meaningful text explaining what was revised in rev.A".

- These cutom properties are created in parts or assemblies and are printed in the drawings. The creation is made with an Excel macro, which makes the job easier than it seems.

- One (and only one) printed version of early revisions is kept as historic purposes.

- In the company we have a management software (for buyng, selling and production management). The revision sate of parts and assemblies is identified in this softwre (I am now working in a macro to automatically syncronise the data of this softwre with the custom properties of SW parts and assemblies)

Regards
 
Another thing:

In my company, the e-mail is a mandatory process for communication. When a new revision is approved, an e-mail is sended to the interested parts. The reading notification is a prove of a controled successful distribution. We provide printed drawings to QA and manufacturing departments, discarding the earlier revisions.

Regards
 
macPT, thanks for the document control methods! I didn't know about the strengths of using these properties. What about exporting into different file formats, such as IGES or STL--these file types do not have such property assignments, do they?

Because we do all our design under the same roof, "tribal knowledge" in document control isn't quite as hazardous as it would be in large work groups with server-accessible documents. Nevertheless, we use a rather universal--but less sophisticated--system to track revisions of whole projects (including parts, assemblies, and foreign file formats).

Essentially, our system works like this:
We keep our design files in one directory (folder). Inside this directory are different projects. Each project resides in a directory (folder) and given the name of the project. Inside the project directory (folder) is a folder with the date of the current revision--so the directory name is a date--such as 01-28-03. Several project revisions can reside within one project directory, each with their own particular date. (This helps greatly for creating and tracking back-up archives.)

For example:
Inside my design directory, I have several projects going at one time. One project, "Widget", has its own directory (folder) that I can manage within MS Explorer. My "Widget" directory has several sub-directories, each given the date of their major revision. My last major revision is a directory named "01-24-03". When we plan to do some significant work on a project, we bump up the revision (not formally, but as a document control method) by creating a new directory with the current date. To make sure we transfer only the most current files into this new directory, we open our primary project assembly (or assemblies) in SolidWorks. Under the "File" menu, we click "Find references". This extracts only the files immediately used by my open assembly and allows me to make copies of all parts, assemblies, and sub-assemblies in my new directory. (This is important, because I often name a part "Widget 01", "Widget 02", etc. when making progressive changes to a part--creating lots of steps in development that I will not need for final revisions.)

Now I have a directory in which resides only my current revision of my project--clearly marked by the newest directory name (date). I can now create a back up copy of my previous revision and safely store it on a CD (or other medium), being confident that we will not accidentally send out an old part revision for prototyping or manufacturing.

As I said before, this method won't suffice for large groups with access to the same files at the same time, but it's a good method for tracking revisions with high efficiency and success rates.


Jeff Mowry
DesignHaus Industrial Design
 
Sheetmetalfan and all,

There is an old fashioned simplification you can impose that drastically simplifies 3D CAD management.

Do not modify form, fit or function of a finalized part.

You designed it. You fabricated a batch and placed them in stock. Your MRP system has assigned a part number to it as well as a location in the warehouse. You have installed a bunch of them in systems you have shipped to the customer.

The problem exists both in SolidWorks and in the real world. Once two or three people are using the same part, any changes in functionality are going to be a nasty surprise for someone.

If you want to modify something, make a copy of it, and register the copy as a new part. Now, you can change anything you want.

All of this is a beautiful example of a computer program accurately modelling the real world.

JHG
 
Theophilus,

These properties are very useful. I use them for many pourposes even to retrieve cost data from our management software. This way I can predict manufacturing costs during new design.

If you are exporting your SW parts in different formats, with a macro you can output the custom properties into a file that can have the same name as the export file (the name will be the key to link the files).

You can organise your job in many different ways. It depends on your product, market, dimension, culture,... We can never say that we work in a better way than others. What is good for my organization can not work at all at yours. There are 2 golden rules: keep it simple, do not duplicate. This way it will be easy to manage and control.

Optech,

In my company we are allways trying to improve our products either by reducing costs or improve quality. That means that our designs are revised in a regular basis.

When we modify some part, our management software tell us what products will suffer from this modification. We check each of them for problems. We have a custom property informing if someone is revising the design at that time. Each designer must check the status of this custom property when using a component for a new design.

These are just ideas that can help someone, but they will not work in all companies.

Regards
 
macPT, thanks for the additional insight. I haven't messed with macros *yet*, but may find some use for them soon, especially as the company and nature of projects grow.


Jeff Mowry
DesignHaus Industrial Design
 
Just a couple of points here.
If you are nameing directories to hold files and naming them by date then these should be in the Yerpian form "03-12-31" yyMMdd instead of the customary USian "12-31-03". File name modifiers should be two digit, 00,01,02,03 etc., not 0,1,2,3,4,5. . . 10,11,12 and so forth. Always use one more digit position than you will ultimately need. They sort better that way.
Optech is pretty much right about not revising/changing a part once it is released to production. Change the number instead. If you are in an R&D environment things are more flexible and you may be doing endless revisions. This area should not use the same numbering system as the production line, however.
To track revised parts, the file name of the current product remains unchanged, "Mypart.sldprt". You can save an old revision as a revision, "Mypart-rev00.sldprt" [save as COPY!] but if it is defined in the context of an assembly you have a part and drawing management issue. Perhaps saving old designs as *.step files will be helpful.
It gets nasty when old revision parts are out there with the customers. I like Optech's solution the best if you have sent parts and assemblies out into the real world.
MacPT has a good way of getting the rev data into the product file and onto the drawing. There is a lot of room to document changes in file properties for drawings, parts, and assemblies. use it and avoid buying expensive MRP programs for a while.
Rather than a paper file of the history you could put out a *.dwg file into a project history directory. This file could contain the rev level in the file name.

Crashj 'rev B of this post' Johnson
 
When I was new to SW (99) I was given a project to modify an existing product for a specific customer. The first thing my manager did was to copy all of the files into a new directory so that I could play with them. I wasn't the only one new to SW and this turned into a nightmare. Worse still was the fact that the company didn't have a standard naming scheme for parts or assemblies. They did actually but didn't apply it to filenames. Bushing is a nice name but a second Bushing (a different size, whatever) never gets loaded. I spent a LOT of time fixing the file names and other problems as I ran into them. Then the project was finished and I found that I had to work on the original files that had the same problems. Some of those problems still exist.
We eventually found a solution that worked for us. Filenames were always '123456-789 - Description' using the normal Noun, Verb standard. We also created a 'Parts' and 'Purchased Hardware' directories. The 'Parts' directory contained sub directories based on the part number so that they would only contain about a 1000 Parts and Drawings. The 'Purchased Hardware' directory contained subdirectories named after the type of part it contained.
A new project would get a separate directory and all new parts would be added to it, Purchased Parts were automatically added to the 'Purchased Hardware' directory. Revisions started out at A1 and clime. When the project was finished, all valid parts and drawings would be moved into the correct 'Parts' subdirectory and their revision letter would be bumped to 'B'. Only the top assemblies and special parts that did not follow our part number system (normally reference items) were left in the project directory. Everything else got moved.
It worked for us. The only reason that I mentioned it is that I have had a LOT of problems with parts that do not conform to any naming standard.

Lee
 
My company uses some of several of the strategies previously listed:

- Part and assembly files are saved by their part number - no revision in the name (12345).

- Drawing files are saved by their document number with the revision (PD-12345-A). The "old" SolidWorks drawing is destroyed.

- Drawings are printed to .pdf files for distribution and saved with the same name as the SolidWorks drawing. These are our controlled documents for quality audit purposes. Old .pdf file are kept for historical purposes.

- The revision block contains the revision letter, Engineering Change Number, a brief description, author, approval, and date. The Engineering Change can be referenced for a detailed change description. (The EC# can be hyperlinked to the EC document for easy access.)

- If a part is no longer interchangeable as a result of a change it is assigned a new number.

- While a part / assembly is in the design process we assign numerical revision designators to the drawings and label as "Work in Progress". This gives us the ability to track changes without initiating an EC. After validation the part/assembly drawing is assigned an alpha designator and the full EC process is now required.
 
PDM: the only way to fly.
Unless you want to have duplicate files in several directories or have different parts, assys and drawing files occasionally having the same name (both a recipe for disaster) decide on a file naming convention for your designed parts and common or purchased parts (library parts). Put them all in a single folder or decide on a folder system.
But first and foremost stop trying to be clever and invest in a PDM system.
There's no way to have an accurate history of an assembly with all the parts at a certain rev state without a PDM unless you want to create a copy of everything in that assy and all the drawing files into a unique folder which represents a snapshot of the condition of all those files at a certain point in time. Same goes for a part but of course then there are only two files involved. So every time you up-reved an assy you'd have to copy everything in it so that you can be sure when or if you have to call it up it would accurately reflect everything in the assy at that time. Which means duplication of files many times over and a lot of headaches.
PDMs are designed to handle this complexity with the additional benefit that it is done with one database. I've done it both ways and would insist on a PDM. It's well worth it.

Bruce
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor