Drawing numbering system 14

[Adrian2]

Dear Folks;

Back in the old days, a number for each drawing sheet was quite sufficient. Now with seperate drawing, part and assembly files I was wondering if anyone can share a good numbering/recording system for keeping track of drawings.

At the moment I record my drawing, part and assembly numbers in a spreadsheet which allows me to search or sort my work for particular information. But of course this is not an optimum solution for large numbers of drawing files.

Best Regards

Adrian D

 

[EdDanzer]

StarrRider,
Sorry to harp on the subject of less digits, but as the owner of a small company I have paid the price of typographical errors. We have a 6 character semi-significant numbering system covering over 20,000 different parts and assemblies. Some of the parts I can remember, the majority have to be looked up for accuracy.
Most of these parts have a manufactures part number as one of the fields in the custom properties, so the purchasing person can order the part.
Just taking the information off the BOM for ordering still has at least a 1 per 1,000 digits error that causes incorrect ordering of parts. The person opening the package may not recognize the error, so the assembly person finds out when they need the part. This usually means air freight to correct the problem, plus the time wasted getting RMA number and repackaging the part and out going freight. This time and expense far exceeds the lookup cost.
As I said in my first post, “I hate part numbering and tracking of inventory”. To date I’m not sure there is a good method, our current system gets a C or D for overall value.
If someone figures out a good system they should be able to sell it.

Ed

 

[MadMango]

Lee, if you've ever ordered DU Bearings, they use significant part numbers like 08du16 and such. The first 2 digits represent the diameter of the bearing and the last two digits represent the length. "The attempt and not the deed confounds us."

 

[StarrRider]

EdDanzer

I sympathize and think I understand. With appropriate controls in place, a good Accounting/Inventory Control software package should eliminate most of the problems you are describing. I wish I could provide you the name of a good program but I cannot. The last company I worked for had ManFact and I used a lot of other names to describe that system. It did do the job but it was very difficult to learn, had more twists and turns than a snake, and had the look and feel of an old DOS program (on a NT platform). Several years (4) before that I used MASS 90 and I wasn’t terribly impressed with it either. If you decide to start an evaluation process, check out

http://www.2020software.com/

they claim to have the top 20 packages and provide Free Demos and Selection Assistance.

Once the data is entered in one of these systems, ordering parts can be made automated (internal as well as vendors). You have to set up scheduling but they will generate your P/O as need without any manual input. They also track the P/O so you’ll know when something is late and can start annoying your distributor.

The process we employed for new parts was:
· Original part selected and P/O generated (by hand) by the Engineer – If acceptable
· ECO to release the new part and Data Entry form filled out with a copy of the catalog page or spec sheets (with the P/N nicely circled) for historical purposes
· ECO comes back to the Engineer for final approval with a printout of primary fields

Most of the ordering problems that I saw were related to older parts. When the company was a lot younger there were no controls on data entry, at least the last step was omitted. As a result, the primary fields (P/N, Description, Vendor, Mfg. P/N, and Allow Alternates) were – Ahhh – varied, often blank, and no historical data was preserved.

A fitting might have a Part number of 1/8ELBOW with no description. So if you needed to know if it was a Male/Female, NPT/BSPP/Barbed, or the material you had to pull one from stock or use the Mfg. P/N and find it in their catalog (if you could find one).

 

[DigiBob]

First off we have a CM dept. that keeps a seperate excel Master drawing list for each program and all new drawing numbers are requested thru them. They use a combination of 6 digit non-significant numbers with a suffix identifier and the revision (306124NDXA)this is what we name our SW drawing files. The "ND" in this case stands for an Installation Drawing and the "XA" is the preproduction revision. The number itself may be a 30 or 306 series for a particular program but not always.
For our Solidworks Assemblies and parts we use significant names(usually the corosponding drawing title). Since our CM don't trust SW users to maintain the source files, we have to give them to CM before they will release any drawings. So what we currently do is give them rapid draft files during the pre-production phase and then when the drawings are baselined, we give them a zip file of the full model with the upper level install as the zip file name(306124ND-). This would include all the parts, drawings, and assemblies under the install (usually use find references).
We have a lot of facilities spread out over the U.S. so If someone needed any of the files, CM could just send them a copy of the zip file.
So far we have not had any problems with this method, but only time will tell.

Bob

 

[StarrRider]

MadMango

The last company I worked for is typical for most of my employers. With them, your DU Bearing P/N 08du16 would end up with a part number like 6562-1012. The description would probably be BEARING, DU, 08x16. The filename for the model would be Bearing, DU, 08x16 – 6562-1012. That file would be stored in the \Hardware\Bearings directory.
We normally included the Manufacturers name and P/N but it wasn’t used. A special Vendors database was maintained for all Manufacturers or Distributors and a Data Entry sheet would include a copy of the catalog page showing the bearing in question.

The intelligent systems that I have been referring to would have a category like 656 (above) for all Bearings and a subcategory of 2 for DU Bearings. I think you can see the problem with this. That is, providing no OTHER subcategory was provided.

This raises another question though. From reading this string I started getting the impression that many of you only use the P/N for a filename. This would work fine if you only used SW to open and insert parts. I don’t. I use Windows Explorer almost exclusively to open or insert parts, assemblies, and drawings. Personally, I find that a lot faster than using SW and having to navigate to the correct directory constantly. I usually have 2 or more sessions of WE open in different directories (Project/Hardware).

Lee

 

[StarrRider]

OOPS

We normally included the Manufacturers Name and P/N in the Summary Data (Not a Custom Property).
A Drawing always started it's life at Rev. A1 for pre-released parts. All parts were released at Rev B. Only a full ECO bumped Rev Letters. Markups made incremental Rev changes (B1).
Purchased Parts used an index driven numerical system with the format xxxx-xxxx. We maintained a manual hand written log for these parts.
The format for Manufactured parts was xxxxxx-xxx. The suffix was intelligent but didn't make any sense and was often ignored. The first 2 digits of the PN was project oriented. The filename was ‘P/N – Description’ and were stored below the Fabrication Directory in a folder for the project. Originally, we created a hand written log for these files as well. I later created an Excel for them. After we lost half our workforce, we stopped logging the P/Ns entirely and relied on Windows Explorer which – almost – worked.

Lee

 

[MadMango]

I like to place vendor information in Summary Data too. It makes it nice when you hover your pointer over the file name in Explorer or SW, as it displays this info for you.

We create Source Control Drawings (or Vendor Item Drawings) for every purchased component, and give it our own 5 digit number.

And, I think you might have stumbled across an enhancement request. It would be nice to be able to set-up some "favorite folders" across your network in SW, that you could directly pull files from. "The attempt and not the deed confounds us."

 

[StarrRider]

MadMango

I believe that is what they originally created the Feature Pallet for. All of you favorite directories can be added to it. You can Drag parts into an assembly or R-Click to edit them.

There are a couple of problems with using the Feature Pallet for this. The main one is that it is SLOW! The speed is comparable to Windows Explorer when the display Icons setting is turned on. Opening a directory with a couple hundred parts can easily take a minute or more. Second is the fact that ONLY parts are displayed. Many of my insertable parts are actually assemblies. Finally, it does not include the browse over feature that you just mentioned.

However, adding a enhancement request for a Favorites Directory to launch Windows Explorer (or something like it) would not be a bad idea.

If I could have only one enhancement request granted by SW that would not be it. I would ask (and have) that SW Explorer loose the Outlook UI and adopt a Windows Explorer UI allowing a fast preview of files (everything SW including Macros).

Lee

 

[SnowCrash]

All of this is worthy of a book on the subject, so there must be one out there. Anyone have a cite?
Some thoughts on numbering systems I have used:
The ten digit system someone mentioned is like the UPC code. Five digits for the manufacturer, five for their products. This would be useful at the retail level, but is a force fit in manufacturing. It might be helpful for purchased parts except all the control is in the hands of the vendor. This does not help when you multisource a part. Also, UPC is to be superceded with a system from EU eventually. (Surprised? You shouldn't be ) ;-)

A long, descriptive catalog number can be useful for a customer to select say, a valve or a cyclinder. Your internal manufacturing system may not need that complexity.
A five digit part number is not enough, go for seven.
The current revision part is the plain file number [xxxxxxx] with rev level and date info in Properties. Old revs are 'saved as' copies [xxxxxxx-A].
All drawings related to a part are saved as sheets. I have used drawings which were design, production, inspection, customer, and purchasing variations. SW handles this beatifully.
Configurations can be handled with dash numbers, ie., xxxxxxx-001 is a part number while the base number xxxxxxx is the file name. Signifigant dash numbers are inevitable in some products like connectors for material variations and number of positions.
Signifigant number systems inevitably fail but are handy for the person who initiates the product line.
Signifigant number systems fail because of entropy. No system stays organized for more than a couple of management roll-overs. They also fail because too many numbers get wasted.
I now use a system where the first three characters of a part are customer ID alpha characters like SUX. What happens when the customer name changes? What happens when you sell the same part to another customer? Doh!
I was also struck by the though that the most useful part number for us is DNA. It uses only four characters arranged in a long signifigant word that is actually a build list for the, errrrm, product.

Crashj 'just thinking' Johnson

 

[DennisD]

We have learned to take advantage of the long file names allowed in Windows. So much of our stuff was set from our ACAD legacy with the 8.3 file name restrictions. (One place I worked for had developed a "base 30" numbering system; 0-9 plus 20 alpha characters. We had a simple routine to convert forward and back. Key in the part number and out pops the base 30 numbering for the filename. Wow!)

When we converted from Autocad to SolidWorks I was able to push through something which could have been done even in ACAD. Essentially I was able to take advantage of the "upset apple cart" and get some other changes to our mindset. Our filenames used to be 8 characters consisting of a 6-digit part number (where the first character was an alpha) followed by two characters which indicated the rev level and sheet number. All sheets were separate files.

My heartburn with this was that since the part numbers had no smarts to them I was always having to run all kinds of searches in our MRP system in order to find the part number. Now we still start our file name with the same six characters and add the rev level, but we no longer show sheet number since we keep all drawing sheets in the same file. The biggest difference is that we now add the part name. Our file names now look like this:

S123450.Power Supply Chassis - Product such-n-such.SLDPRT

This would be part number S12345, initial release (rev 0). We use the same convention for SLDDRW and SLDASM files.

Taking advantage of the long file names and allowing the use of multiple dot delimeters has made our life a whole lot easier. Now we can search on the part name, which is always easier to figure out.

Incidentally, we have also established a policy that whenever an existing ACAD drawing is changed it is at the very least sucked into a SolidWorks drawing and given the new naming convention. Preferably the part is also solid modeled, but we have a bunch of lazy asses and first line management that is too busy to force the discipline.

Though this could have been done with ACAD, it wasn't. By making the change to SolidWorks we were also able to implement this change which cost us nothing but has payed tremendous dividends.

- - -DennisD

 

[tluxon]

Two things that are very helpful:

1) Do everything you can to avoid using the Part Number as the drawing number. This would preclude you from being able to have multiple configurations on a single drawing, and fosters the misconception that a document number and a part number are the same thing.

2) Include the revision level in the drawing filename and match that rev in the SLDPRT/SLDASM filename. You don't want to ever have two drawings anywhere in the universe that have the same drawing number and revision, but don't look identical. Even one teeny weeny difference brings into question the integrity of the control system being used.

Tim

 

[MadMango]

I'd like to advise against including revision information in the file name if your company ever plans on growing to the point where they will have to use a PDM solution to keep everything straight. You will have to remove this revision information later, and it creates a lot of necessary work that could be avoided. If required, revision iformation should only be used for history tracking of changes. "The attempt and not the deed confounds us."

 

[StarrRider]

Tim (fluxon)

I do not understand the logic behind either of your recommendations, mainly because they are 180 degrees from what I have learned or done in the past.

The first simply isn’t true. I have made several multiple configuration parts. An example would have a P/N similar to 123456-101 thru 123456-205 and each would have a slightly different Description. I do try to cheat and make these drawings tabulated. When I do I add an extra configuration named DOC and use that in the drawing and insert a manually created spreadsheet with the Part Numbers, Description, and the dimension values that change. I think that an automatically updated spreadsheet is possible, but I’ve never taken the time to try to make it happen. The drawing does not have to be tabulated. I have made several drawings with multiple sheets. I do differentiate our file naming standard slightly for these files by making it “123456-101-X – Description” for both the model and the drawing.

The second might work, if you have a PDM that allows you to work that way. I sure as hell wouldn’t want to do it manually. You would have to open the drawing, the model, and every assembly it was used on and start doing a SaveAs to both with the new revision letter, then Zip the original files to get rid of them just in case you missed an assembly. That is a lot of work for absolutely no return.
Dropping the revision letter from the file name makes a lot more sense. The drawing file will always be linked to the model and it eliminates the need to locate and update every assembly it was used on. A historical version of the drawing can still be maintained for each revision. At signoff for an ECO, your Documentation Control people can open the drawing and do a SaveAs to a TIF file adding the revision letter. These are large files so promptly move it into a Zip file with the same name. The resulting Zip file is smaller than the SW Document file.
That may save your history data, but sooner or later you will open a Drawing and find that it does not even slightly match the last paper version that you have. After 3 years of working in SW, having established procedures, educated people, and creating Configurations dedicated to the Drawing, I still open Drawings and find changes. Balloons are missing or pointing at nothing. The BOM is changed. A view will have a dozen extra items visible. Normally, this is because someone was careless when opening an assembly and managed to hide or suppressed something in the wrong configuration. Not even part drawings are impervious to weird unexpected changes.

Lee

 

[macPT]

Tluxon

1 - We DO use part number to name the file. When it hapens to have a part with configurations, the file name will be 12345678XX (that means that it contains the parts 1234567800, 1234567801, 1234567802,...12345678NM) otherwise it wil have the full difined name 1234567800.

2 - We DON'T use the revision number of the file name. This makes the changes done very easely (the product structure does not need to be changed if a component is revised because the filenames are the same). The revision number and it's definition are configuration specific properties of the part/assembly. The documentation integrity is mantained because we only keep the last revision on the server (as simple as that).

We live perfectly well with this system and it as been proven to be strong and simple to use. But maybe it's not the case for other organizations.

As I allready said in other forums, we can never say what is wrong and what is right. What is good for someone is not necessarely good for others because many things change: the product, the organization, the strategy, the market, the people,... We can only share ideas and experiences so each one of us can find ways to improve it's system.

Regards

 

[tluxon]

Lee,

You are entitled to your opinion but I respectfully disagree with you. Let's not be insulting by saying an opinion isn't "true".

On your first point, I'm having a difficult time understanding what you're trying to say. If you have experience with configuration control you surely recognize the importance of keeping document numbers and part numbers related but two distinct systems. In your example of PN's 123456-101 thru 123456-205 I hope you plan on using a drawing number of 123456, even though the referenced models could be named by PN.

On the second point, I'm responsible for maintaining my own project design control files from inception of design. In my experience, I have found it important to be able to reproduce history and occasionally have significant design changes that can diverge two or more ways. Frequently, I take advantage of part designs several iterations old. Your last problem is avoided entirely as long as released (history) drawings & their driving parts are saved in a read-only folder. Simply create a rev of each part that matches the rev of the drawing it currently resides in. Maybe it seems like a bit of work, but it's quite simple and prevents the headache you described.

Cheers,

Tim

 

[StarrRider]

Tim (fluxon)

I was not trying to insult you and I apologize if you think I did. I NEVER intentionally insult anyone. I don’t have to; it just works out that way. Quite often I end up looking like a beached fish, when I realize I did while trying to figure out what I said. We all have our own problems, and that is one of mine.

With that said, how would you react if someone told you the sky is green – and they meant it?

You had trouble understanding the first point. OK. I’ll try it again in a different way.

If I were making a – frame out of 1x1 angle iron as an example, I would probably need several different lengths of that material. Lets stipulate that those parts are all be the same except for their length.
I could create each part as an individual model. If I did this then I would need a drawing for each of the models that I created.
I could also create a single model, add a design table to it and use the resulting configurations in my assembly as unique parts. I can also represent each of those parts in a single drawing if I have a table in it. That is the definition of a tabulated drawing.
What I described earlier is the method that I use to create a tabulated drawing. The side view of the angle would be full detailed and the length would be modified to say ‘SEE DIM A”. The table would contain the P/N, Description, and DIM A. Now to make all that happen, and to ensure that my drawing does not change if the wrong configuration is changed, I would also add a ‘DOC’ configuration. This configuration would never be used in an assembly; it is strictly dedicated to the Drawing and allows me to have a ‘Special’ P/N and a Generic Description for the Drawing. If my part numbers ranged from 123456-101 to 123456-205 then I could use 123456-101-X for the DOC configuration.
Most Documentation Systems have exceptions to the rule. A good system should have a ways to visibly identify those exceptions. The -X following the P/N indicates that there is something different about this drawing.
As for the file name, it is handled in exactly the same way. If a normal file name is ‘123455-101 – Description’ then both the Model and the Drawing would use the number ‘123456-101-X – Generic Description’.
We could have used ‘123456-101 – 205 - Generic Description’. That was rejected because tabulated parts have a tendency to grow over time and adding a new P/N would mean that the file’s name would no longer be accurate and would need to be changed.
The downside – there is only one that I know of. Any time that an ECO modifies any of these parts then every one of these parts has it’s revision level bumped up a letter.


When AutoCAD and programs like it first came on the scene, companies were forced to change their systems to use these new tools. There was a great deal of resistance to this but DOS only allowed an 8 digit file name with a 3 digit extension and AutoCAD claimed the extension for DWG. Only 8 digits and one of them had to include a revision letter while another had to be reserved for a sheet number because AutoCAD (at that time) would only allow a single sheet drawing. This resulted in a 6-digit part number with a Revision Letter and a Sheet number.
SolidWorks on the other hand (I will not go into Pro-E!) is not so restrictive. They changed the system so that there are 3 separate kinds of files but those files are still linked internally. A Drawing KNOWS which Part or Assembly it belongs to and they KNOW where the drawing is. An assembly also KNOWS all of the Parts and Assemblies used in it.
Most companies again tried to maintain the status quo, insisting that a revision letter be included in the filename. The problem with that is that those linkages exist. Changing a files name does not alter those linkages. If Drawing A is copied or renamed to Drawing B it will still open Part A if that was what it originally did. The same thing applies to assemblies. So if a revision letter is included in the files name, then to bump a revision you have to open each file that is referenced and do a SaveAs to each of them. Normally that is a lot of work with virtually no reward.

I was referring to finalized parts and drawings, NOT to an R&D project which is what you are describing. With an R&D project, where you have to be able to jump back to an original design when something doesn’t pan out, you are correct in stating that your historical models have to be maintained. I still would not include a revision letter in the file name because of the amount of work that it entails. What I would do, and have done, is create a subdirectory below my project directory labeled ‘Rev A – 2-21-03’ and copy my entire project into it. That is fast and painless. On big projects I do that every Friday night before going home, or when I want to try something that I’m not sure will work. When the project is completed, these directories are deleted. I also keep an excel log to know which drawing have gone down to the shop and which have not.

Lee

 

[macPT]

tluxon

For R&D, in fact we have a different numbering system. Each R&D project have a code and the parts/assemblies and their drawings have the numbering system xxxyyvnnn (xxxyyy = R&D code; v = version of the project; nnn = sequencial number).

We have the following rules:
- each drawing as the same number as the part/assembly
- the last approved version is the one with no revision state in it's filename. For example, 068032001.SLDPRT can be in the actual approved revision A. If I modify it, I will save as 068032001_A.SLDPRT, for history porposes, and modify the 068032001.SLDPRT whitch, internally, will have it's custom properties updated accordingly (they will refer to rev. B). For another revision, I will save it as 068032001_B.SLDPRT and modify yhe 068032001.SLDPRT, and so on

Regards

 

[StarrRider]

macPT

I think I like that approach. What I do is fast and simple but I have a LOT of duplicate files to deal with. I failed to mention that I do use a File Management program (PowerDesk) to help eliminate them, possibly because it does not work very well. SW insists on constantly updating files that I know have not been changed. I have never understood the logic behind that. I know I could keep them in a Read Only directory, but then I would have to deal with error message after error message every time I did a simple save.

 

[EdDanzer]

I have enjoyed observing how other companies deal with part numbers and SolidWorks to make products. As the owner of a small company and the person who pays for the mistakes, I now understand why large companies costs are so high to develop a product.
It is not my intension to make any one mad or insult them, so don’t take the following comments to heart, these are observations from a person who has paid good money for mistakes that are easy it eliminate. Yes I do still make mistakes, and that doesn’t mean I’m happy with every project, cost constrains, time constrains, and other limitations effect the out come.
Since the buzz word collaboration is frequently used in manufacturing, and being a small company, designing products that are manufactured in small quantities, and upgraded or modified frequently, part numbers and drawings can cause more unnecessary expense than any part a products life cycle.
When a person designs something the people who manufacture it must deal with the part and drawing numbering to complete the task of converting the raw material into a finished product. Every engineer should have to take a set of drawing they know nothing about and order, machine, weld, deburr, and assemble this item using drawing with several rev numbers for each part, and sub assembly, tracking the total time spent completing the project. Then do the same for a product with part numbers that item specific. My experience is you can save from 10 to 50% in time and cost to manufacture by making the process stupid proof.

SolidWorks users who don’t open up every part, drawing and assembly, and resave them every time there is a major update will pay a high price. My first bad experience cost $6,000.00 in 1997. Today I loose about 5% productivity when working with older files.

Use configuration with caution, these are like a part number or separate file, loose track of how they work and somebody will start writing checks to fix the mistake.

Remember the people who use the drawings may not be much smarter than the material they are working with, and even the best can wake up with their stupid hat on. If the drawings or numbering system cause people to make mistakes in manufacturing, it is the engineers job to help these people succeed, your job will depend on it sooner than later.

A 10% increase in designing and producing a drawing package that eliminates mistakes and provide for simple change can pay for its self in the first iteration of a product, but for sure buy the fourth iteration. Changes will have to be made in every product during its life cycle, using a part number once, creating a new one for each change will reduce total cost over the life of a product. This concept is similar to serializing each item, but in a broader term.

Know your customers! When you design a product many people will interact with it during it life. The person who engineers the product will actually spend the least amount of time actually interacting with it during it life. The owner the most, the parts department next, then the service department, then manufacturing, then purchasing, then accounting. Now if a product needs constant engineering help it must be a poorly designed product, or poorly documented one, and the cost to everyone will shorten the products life, and hinder the company’s ability to sell more products to these customers. If you think the people who interact with this product the most care about what the part number means, do a survey. If you chose to do a survey, you should ask them about the parts and service manuals also. I will warn you, the people answering the survey may be brutal.

Good luck with your projects, and I hope you can make your customers happy.

Ed

 

[cadman98]

This is an interesting discussion! We have been debating many of these same issues also. We decided to go with a numbering scheme which has no intelligence associated with it. Why? Because sooner or later, they all fail.

My 2 cents worth: You really are pointing up the need for a PDM system such as SmarTeam or similar.

The advantage, as I see it, beyond all the revision, check-in/check-out, linking abilities, etc. is that searches can be conducted on several "fields" i.e. - filtering, and the drawing number no longer plays an "intelligent" role.

I guess that's why things keep getting invented. Everything gets more complicated, more people involved, etc., etc.