naming convention help

We're finally talking about using a naming convention here at work
(you cant imagine the mess we have right now..it's about time), but i
was wondering what you guys use, and what would be best for our
situation. I'll explain what we need the convention to be able to do
for us and what we're (somewhat) proposing.

First of all, we'll need some sort of identification number (say..
123456) to identify the part/product. This is where it already gets
confusing.. Should we use a new number for every part? sub assembly?
assembly? project? We're a machine shop (conventional mills, lathes,
CNC's, welding) that's dabbling in somewhat large assembly designs
(automated assembly lines, large heavy gauge sheet metal dies, etc),
so we do everything from small single part designs, to ~500+ part
designs..

Next would be a sub-assembly/part number like -001, -002 (ie the full
number would then be 123456-001).. should we use this as a way of
giving a unique number to all parts, assemblies and drawings? or
should drawings use the same number as the part/assembly they
represent? Our plant manager comes from a more autocad background and
is more used to working with only drawings. Using solidworks increases
the management to parts and assemblies, which is somewhat foreign to
him, and therefore confuses the system just that much more . Up to
now, i've been using unique numbers for every part and assembly, then
if i did a drawing, i'd use that same number so that i can easily
associate them together (for example, part 123456-001-01 would have a
drawing named 123456-001-01 also, and not 123456-002-01 or some other
secondary number (last number being revision number, explained further
down)). It was brought up that we might want to give the drawigns a
unique number, and that within the drawing you'd point to the part
name thats being shown..That makes it somewhat difficult to figure out
what drawing represents a part/assembly though when looking at a
folder of files.

Next would be a revision number, -00, -01, etc.. The full number would
now become 123456-001-00. Do we keep all older revisions in the same
folder? do we archive them somewhere else? (we dont current have any
PDM software, i actually haven't looked at PDMWorks, how much is the
upgrade to office professional? we have office here..) If a part is
used in more than one assembly, how do i know this when it comes time
to update the part revision? should i be doing that? The reason i ask
this question is that we keep some parts in stock, and if they have a
different revision number, it automatically negates interchangability,
which may not always be true.. the new revision might just as well fit
in that other assembly..but it's still referencing the old revision..

My other problem comes when updating everything to a new revision.. If
i change a part's features, and save as a new file name (since it's a
new revision) can the drawing associated with it be easily "updated"
to that new part file? (if it wasn't open when i was saving these
changes, it'll still point to the first revision). From my limited
experience, i haven't found a "replace part" in drawings like there is
in assemblies..

Well, thats all for now..It might be a bit of a long post, but I'd be
greatful for any insight into the proposed system, and how to use it,
or even a new system altogether. This system was brought up only after
a few discussions on the subject here.. so it's nothing very indepth,
but i dont know how to proceed from here.. None of us really have that
much experience in setting up a system like this.

Thanks,

André Richard

 

What we use here is a unique 6 digit number for each Object

Hardware 10xxxx
Hydraulic fittings 15xxxx
Paper (manual, decal etc) 16xxxx
Electrical 17xxxx
Modified Bought Parts 20xxxx
Top Level Products 30xxxx
Sub-Assemblies 40xxxx
Individual Parts 41xxxx (anything we make out of a single piece of steel)
Individual Parts 42xxxx (meaning we have more than 2000 individual items)
Materials 50xxxx

Using this allows you to reuse parts that are on many sub-assemblies instead
of using the sub-assembly to dictate the name of a part making it
sub-assembly specific. Bottum UP not Top Down if you will. We use the same
name for each drawing as the part or assembly it references. This makes it
very easy to know what drawing to look for a specific part vice-versa.

Yes if you do save as and the surfaces in your drawings are the same just
moved or something. When opening a drawing there is a button labeled
references this allows you to change the file name associated with the
drawing. All dimensions that can update, will. For revisions here we note
in the revision collumn and forget saving as because there are just too many
files that reference it and you never know which ones need to be updated.
Plus you endup using alot of disk space keeping all the old copies of every
part, assembly, and drawing that you revise. With file sizes that climb to
10MB quite easily you can fill up a hard drive quite quickly since this time
last year we have gone from 9GB free space to 1.5GB free space with only 3
engineers adding to the mix.

Just be sure you don't creat too much work for yourself.

Regards,

Corey

 

Here are my suggestions in a nutshell:

DO NOT include revision information in the part number Use custom
properties instead. If you need to keep models of old revs around for
reference, develop an archiving system or use PDM or just archive a PDF
of the drawing.

All part numbers should be dumb, simple, sequential numbers. Do not
assign categorized parts to certain part number ranges (like purchased
parts 10xxxx). The reason is that part categories can change (perhaps
you decide to produce our own instead of purchasing it or vice versa).

Keep the model and drawing number the same

 

I agree with Arlin regarding part numbers and custom prpoerties, (we use six
digit categorized numbers and are nearly out of our allocation). If you are
going to be using SWX in a multiuser enviroment with lots of
assemblies/revisions ect, I strongly recommend that you invest in a PDM
system of some kind to manage your data and revisions (have a read of
Sean-Michaels post on 5th Dec), some will even handle the allocation of part
numbers for you.

Cheers

Brian

 

thanks everyone for your ideas... here's what i've come up with, and
what i've proposed to the plant manager.. he's thinking it over right
now..though i'm still open for more ideas )

Numbering:

123456-001

6 digit number to identify product, whether it be a single part of
multiple assemblies.

plus a 3 digit number identifying a part or assembly.

Parts/assemblies will have the same name as their respective drawings.
If more than one page of a part is needed to describe it, i'll just
use more than one sheet.

The revision will be stored in the custom property field.

Here are the steps i'd use when creating a part for the first time:

*Get a new 6 digit number.

*Start modeling parts and assemblies by giving them a new 3 digit
sub-part number.

*Create a drawing for whatever part/assembly needs one.

*Once a drawing is finished, a pdf version of it is created which
includes revision and version numbers, ie: 123456-001-01-01.pdf

note: a revision is when the part actually changes, and the old part
becomes obsolete, a version is when a modification was done on a
drawing (ie missing dimensions, reorganizing layout) but no actual
part dimentions have changed, making both versions technically
equivalent. Using this can keep track of what we sent to
suppliers/sub-contractors.

Here are the steps i'd use when adding a revision to a part:

*Zip the part and drawing file in a zip file identifying the revision
it was. in the case of the first revision, the parts i'm zipping are
revision 0, so the file would look like 123456-001-00.zip. I'm not
quite sure if i should just leave these zips here or archive them
somewhere else, but thats not too important at this point.

*Do my modifications on the part (and increment the revision custom
property)

*Add revision details to the drawing (that lil triangle) and add info
in the revision table. and of course modify any details in the drawing
itself that the revision brought up.

*Create a PDF version of the new drawing. ie: 123456-001-02-01.pdf

This setup negates my using the same part in 2 assemblies (unless i'm
certain *any* revision to the part will be applicable to the other
assembly), since it cant know what revision of the part i was using in
that assembly (can it?).

My suggestion was: Create an equivalency document/database.

If i have part 123456-001 (revision 1), and i want to use it on
project 123457, i'd copy the part (and associated drawing) over, and
rename it according to that other assemblie's current structure, so
lets say 123457-004 (revison 0). the equivalency document would
indicate that 123456-001 (revision 1) is equivalent to 123457-004
(revison 0). In the case that we have parts stocked, we'd be able to
find out just whats equivalent (stocked parts would need a revision
identification). If part 123456-001 ever becomes revision 2, the
equivalency still holds for stocked parts, just not for any new part
created. If at some point I load up the assembly using 123457-004, i
can check if the new revision of 123456-001 is applicable to it, and
if so, make the necessary modifications (copy, paste, rename), and add
a new equivalency in the database for stock parts purposes (123456-001
(revision 2) is equivalent to 123457-004 (revison 1))

I think thats it, but i'm sure i'm forgetting stuff. It's nice being
able to ask people what they think and what they use.. Evereyone has
pretty much a conflicting idea on these systems at work, and eveeryone
can find a flaw in everyone else's design.. never-ending loop..

Andre Richard
Design Engineer,
Gautreau Machine Shop Ltd.

 

Andre,

Using your example below could you explain to me what happens in the
following situation?

1. Product 000001 consists of 100 parts (each following your
numbering/naming convention). One of the parts 000001-001 is a red
part.

2. You decide to create a new product 000002. This product is nearly
identical to 000001 with the following exception: A single red
anodized part is replaced by a the same part but anodized blue.

My interpretation of your proposed schema suggests the following.

You are going to create a new finished product 000002. You are then
going to rename 99 identical parts (no physical change)and drawings to
000002-002 / 000002-100. You will create a new part 000002-101 (blue
part)

This example illustrates why intelligent numbering schemas are not
recommended.

You've just taken a relatively straight forward process of copying an
top end assembly (product) renaming it - and adding a single part. And
turned it into a major undertaking. In addition to the direct costs
associated with this schema (renaming time & generation of PDF files),
you've also jacked up the indirect costs exponentially (trying to keep
track of "equivalencies" still requires someone to enter this
information into a database). I will not even hazard a guess as to how
many possible mistakes will be added to this process during the
"conversion process". This is a very expensive proposition for any
company.

I am also unclear as to how you plan to enforce this schema on the
company and who will be responsible for its upkeep. It has been my
experience that since this type of schema adds to the workload of an
individual - that the only one who will follow it is the author.
Subsequently, when that person quits, transfers, or is promoted, the
schema is abandoned since nobody else in the company will buy into a
process that adds to their workload.

My suggestion is any schema you adopt should follow the principle of
reducing the cost of data ownership - not increasing it. This can be
quantified quite easily to allow you to compare various systems
directly.

Example:

What is the translation of the following piece of engineering data
(date):

02/04/03


Each one of you who is reading this has either interpreted the date
based on their regional convention or is looking for an additional
piece of information
(date schema: such as mm/yy/dd or dd/mm/yyyy or mm/dd/yyyy).

A few might have even tried to figure out where I'm from in order to
determine what convention I may be following (I'm Canadian so our
dates follow the
British convention and not American). However, guess what my regional
settings are on my computer.

Maybe one of you would respond to this post asking for the schema I
used to determine the date. If I said I'd pay someone $10.00 for the
correct answer I would get more than one person emailing me directly
for the schema.

Now lets say 10 engineers take me up on my offer and spend 10 minutes
out of their day to get the correct answer. At a cost of 60 units an
hour per engineer we have
10 minutes x 60 units/60 minutes x ten engineers = 100 units per data
(date).

This is a very expensive piece of data.

Now look at the aternative representation of the same date:

April 3, 2002

Everyone who read this last line knows exactly what this data
represents. There is no need for guessing, assumptions, or getting the
wrong date, it doesn't need any addtional data to support it (schema),
nor does it need any more resources by engineering staff to find the
correct interpretation. The cost of data ownership was the amount of
time each person needed to read the line (maximum two seconds). I'll
let each of you do the math......

Try this technique with any of your proposed naming schemas -- assign
a cost based on who will be processing the data and take your best
guess at how long each process will take. Limit your evaluation to
those tasks that make up 90% of the process based on each
schema.......run the numbers and it will allow you to compare them
"apples to apples".........



Hope this helps.


Len K. Mar, P.Eng.
President,
E-data Solutions

E is for "Engineering"