Experts ideas on Filenaming Conventions with Native 1

Do NOT use the part description!!!!!

Look at the requirements for using Part Versioning and you will see why.

You want to keep the filenames to something that is consistant and short, yet allows you enough room to grow.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

I agree with Ben; do not include the description in the file name. There are plenty of other methods to note this information and the file name is not one of them.

"Good to know you got shoes to wear when you find the floor." - [small]Robert Hunter[/small]

ewh, aside from a PDM system, what are the methods that might we consider?

We use a semi-significant numbering system consisting of eight digits; the first three designate the project/customer, the next two designate the type of document and the last three are a simple sequence. We include an underscore followed by "dwg" if it is a drawing file, another underscore and a revision letter, so 14 characters for an NX drawing file and 10 characters for a part file.
I make no claims whatsoever that this is better or worse than any other system, but it was in place when I started here and has worked well thus far.
As for part descriptions, they are listed in a Master Database maintained by the Data and Document Control administrator, and have been sucessfully migrated to SAP. We will be implementing a PLM system in the near future, and have our fingers crossed as to how well everything will work together at that time.

"Good to know you got shoes to wear when you find the floor." - [small]Robert Hunter[/small]

We use a 6 digit non-significant (721235) numbering system that may include items welded to the main unit (721235-001).
To this we add a dash and revision letter (721235-B or 721235-001-B).
For drawings, we add _dwg to tyhe name.

This allows us to use Part Versioning rules that will load revision D in an assmebly that was saved with a revision B component when the assembly is loaded ata later time. This way our assemblies can always be loaded with the latest components. If we want the as-released components, we just turn off Load Latest in our Load Options.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

I would do the following as it provides flexibility:

All part and assembly files use a dash variation suffix:
(12-123456-1.prt)

The drawing files use just the basic part number:
(12-123456.prt)

Your descriptions would be attribute based.

To set yourself up for part versioning or at least avoid painting yourself into a corner I would think through issues of how you manage data and reflect your work flow and releasing process. The first step is whether to work within the master model system, because using it has real advantages and few disadvantages provided you have thought through how you use the system within its intended design to help rather than hinder managing greater complexity. A big part of that is thinking about how you create maintain and release component and assembly drawings, how often you have to maintain and reissue your assemblies contingent upon minor changes to their components and whether the part naming system supports that.

My solution has always been to use the military versioning system. It is the most flexible and compatible across transitioning from nothing to part name versioning to later organising you data into teamcentre in my view. The file name takes a form that can be similar to computer software versioning. Part123.01.01.01 would work and would Part123.01
You'll probably need to read more about how it works to understand the level of flexibility involved and then it is simply up to you to decide how many levels of increments to use and what they each represent.

The good news with such a system is that it uses the "." period or full stop character (depending on where you were educated) as a delimiter, which legacy naming systems seldom have conflicts with. People just don't realise that you can include some of the punctuation characters in file names. You also find that the system conveniently ignores any confusing with the trailing "." in ".prt".

As for the core part name various systems exist. Some organisations like to be deliberately oblique for security reasons using only numeric combinations that are sequentially or randomly assigned, GM does this. Other companies like to assign meaningful numbers according to a logical system that refers to product modules. There would be a list of modules and sub-modules used to assign part numbers which describe what sort of part it is or it usage in the design. If an engine was module 4 and the sump was sub module 3 then the sump gasket might have a part number that looked like one of the following: 4-3-2, or 004003002 etc, just depending on you you construct and delimit your chosen file naming convention. In many organisations part of the file name will always reflect the project where the design was first used.

Others use combinations of word or alphanumeric based naming. I differentiate between these on the basis that if you use alphanumeric characters for a greater naming range but in the same sense as the numeric methods I described above then you have a differently predictable outcome that you have when you adopt word based nomenclature. The later I choose to avoid (like the plague) because I find it messy and hard to sort and indeed police within a well regulated system.

The NX system won't recognise and police the core part of the file name that you choose to use, but whatever you do you need to avoid having delimiters that conflict with what it will recognise for the purposes of versioning rules should you choose to implement them. What it may do by default (certainly in native out of the box) is append _dwg when you create drawings in the master model system. In my view you might as well roll with that as be deliberately different, but any similarly clear distinction between drawing and model will serve as well.

Anyway I hope this helps. Your next move might well be to suggest your needs and how you'd like to reflect them in more detail so we can offer practical advice about the benefits and pitfalls.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

Thanks for your responses. Let me give a little more background. For our product documentation, it is all revision controlled with SAP. Part numbers are nonsignificant and assigned sequential numbers. Using the design authoring packages we name files whatever the designer wants. As the product design progresses, these formal part number are assigned and these part/document numbers are used to create material records and also used in the file name of the PDF 2D output that is tied to the part. 2D Drawings are still king, although we have been making great strides in leveraging the 3D data for other downstream processes (specifically CAM). The 3D source data for the 2D Drawings is archived in a zip file and released under a document number which must be checked back out and revised if anything changes on the product. There are many defects in this method but they will be worked out with PLM (somehow).

Now, the particular process we are currently working through is for our manufacturing documentation. There are many fixtures, and tooling that needs to be created for the manufacture of the product. Current states is that each engineer is free to call part names whatever he or she wants. They can pull from the same number pool product design uses, or just make up some part description for the fixture assemble and all the components. These fixture parts are not under the same revision control as the product data in SAP. In fact, they are not really under any formal revision control. Some will create one drawing and on each sheet of the drawing set, detail a different component in the fixture assembly resulting in one big drawing set for the definition of many parts. Others will create a drawing file for each piece part using the master model concept. These files get created on local users computers, or the network and they are not formally released where others can access them for sustaining purposes. We have many fixures througout the plant where knowbody knows where the current (or maybe any)design documention is. So if you can imagine several engineers getting together to agree on one standard way of naming files/parts, creating drawing (one drawing for each part or one large drawing set for all the parts) when each of them has their favorite way of structuring these designs etc, etc... It gets pretty heated to say the least. That is what we are trying to overcome and climb a step or two higher up the ladder toward the Best in Class process for this. Yes at first nobody will be as happy as they were before, but later on when a person has made the standard method a habit and has to sustain an assembly designed by somebody else and they see that it is structured the same way as if they had designed it themselve, it will save many hours. I am guessing one extra hour up front for structuring the assembly and file names to a standard will save a minimim of 5 hours later on. From what I am reading here the Best in Class for filenaming is numeric or alphanumeric with maybe some intelligence in what parts of the number might characterize for quick identification. And I further suspect these formats might be the easiest to cleanse and migrate into PLM in the future.

Your thoughts?

My advice, since I what I've known of SAP in the past has been unwieldy and inflexible, would be that if it only cares about the drawing release then let it. Work on setting up a system that names the downstream files for the parent and where possible always treat the model as the master because technically it is quite simply the only thing that makes sense. You can do this just as NX intends and as I described earlier by thinking in more or less modular terms. The drawing file is part124_dwg, and if you're doing manufacturing append them likewise part124_op1, part124_op2 etc. By working in master model concept with assemblies the system will keep track of what revision you worked with as last saved when you toggle the load latest switch under you load options (supposing that you decide to use part name versioning). That kind of flexibility works for most people most of the time. Provided that you're sensible about it you should avoid both painting yourself into corners and making a rod for your own back.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

BOPdesigner,
I can feel your pain... our tooling situation was (and to a certain extent still is) just like yours, with the added complication of project hand-off to different project engineers, so project history tends to be very vague sometimes.
We handle our tooling files by assigning a base number for the assembly and drawing, and detailing the components on that drawing. Components are assigned the base number plus a dash number. This has worked well (where actual numbers have been assigned). It is very frustrating though to have to continually harp on the engineers about the need for proper file identification. Our hope is that a PLM system will force the discipline upon them, since they don't seem to always follow the procedures as written currently.
Good luck!

"Good to know you got shoes to wear when you find the floor." - [small]Robert Hunter[/small]

I'd like to extend this discussion with a follow-on question regarding the revisioning of parts vs drawings of those parts (forgive me if this should be a separate topic).

Consider the case where one has a part, say "1234.prt" and a drawing of that part. Let's say the part is at Revision "A". So the part name is: "1234_A.prt". The drawing is "1234_dwg1.prt". Let's also say the drawing is at Revision "A". If something needs to be modified on the drawing, its revision would need to be incremented (Rev B); but what if this change didn't actually change anything on the master part? What should the new file name be (1234_A.prt, or 1234_B.prt)? Can you have a drawing at a different Revision level than the part it references? Or is it always best to increment the part revision along with the drawing revision?

Thank you.

We often revise drawings without revising the models, resulting in different rev levels. We also list all of the relevant file names on the face of the drawing and since the revision is reflected in the file name, this also serves to note relevant file revision level.

"Good to know you got shoes to wear when you find the floor." - [small]Robert Hunter[/small]

It also depends on your MRP system or what ever is your companies master control system. Does it treat drawings and parts separate or as one?

Some companies allow the drawing to be revised without revising the model. The hard part comes because technically you cannot revise the model without revising the drawing.

Other companies say that the model and drawing file must be at the same revision level. This makes it easy, but adds extra 'same' models if no model change was made.

One company allowed each sheet of the drawing to be at different revision levels. That was fine in the AutoCad days were each sheet was a separate file anyway, but in Pro/E, NX and others it didn't make sense because we had all sheets in a single file. It also precluded using the file revision level to drive the revision block on the face of the drawing because they were always off.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

Potrero,

I think the best approach would be for the user to also change the revision of the parts to match the revision of the drawing. They should match, but I realize that if you don't have a data management tool, this can be tricky and time consuming.

I think what needs to be considered is how your business operates. Assuming that you manufacture, build, and deliver a product you would need to know how these assemblies are built: Are they procured and built using the latest released revision of all piece parts (imprecise) or are they built as the assembly revision was stored (precise).

Mike

In my view and from long experience the revision of the component file name and especially assemblies should NOT have to match the drawing file name. If you do that you're quite likely only making a rod for your own back. Experience in setting up systems in several companies and implementing versioning rules has shown me that this is the natural assumption that people make, and which I have had to disabuse people of many times.

Most of the time changes to components will quite naturally follow changes to drawings. But it is a game of what ifs.

In native systems or even implementations of teamcentre where components and drawings are released by moving them to a different folder or otherwise write locking them then occasionally you may need to tweak minor elements of a model to support downstream processes that don't necessarily affect the drawing. These could be to do with reference sets, attributes, or any other issues with maintaining the geometry. For native systems the point is that unless your revision number is incremented then anyone manually attempting to recover data from a backup could be mistaken in the belief that it is okay to overwrite a changed file. Sometimes it is even decided to go back to a previous design, but no system worth having ever goes back a version it MUST always go forwards or be logically compromised. On other occasions nobody wants to inconvenience downstream users and processes by re-issuing a drawing without sufficient reason. Having the flexibility to divorce model changes from drawing changes grants you the ability to work with real world circumstances so that the system serves you and not the reverse.

When it comes to assemblies then the bigger the product is and therefore the more sub-assemblies then the more unwieldy the task of updating not just one but every assembly through to the top level just in order to ensure that every change is reflected just so that drawing releases are coordinated with model changes. This is the big one because at some point the task becomes literally unmanageable. Time and again you'll find yourself creating changes for "pictorial reasons" alone, updating views almost as an excuse to revise top assemblies for no good reason.

The assemblies themselves retain an accurate memory of how they were last saved, even if you have versioning rules then you can still compare the difference when load latest is enabled or turned off. Systems that can't comprehend this or try to work against the software make life difficult because constant human intervention is required to make the system work in spite of itself instead of because of itself.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

Guys,
Thank you for the detailed responses. Hudson, I definitely can see your point, particularly with respect to the impracticality of needing to somehow increment all levels in large, complex assemblies.

Assuming one keeps part and drawing revisions separate, then is there a Standard way to indicate which part revision is being referred to, on the drawing? Should the "3D CAD MASTER PART NAME" be the go-to reference on the drawing (so the name would be 1234_A.prt etc)? If the part rev is incremented, then the drawing would need to be updated to point to the new master part?

Finally, is there any value in assigning a revision letter to the drawing file? Or just leave the drawing revision to be handled within the file itself but not reflected in the name (ie: the same 1234_dwg1.prt is used even though it is now on revision B; vs having multiple drawing files, 1234_dwg1_A.prt, 1234_dwg1_B.prt, etc).

Sorry for asking all these questions, but your answers are really helpful so far, and may aid in preventing us from going down the wrong path (with far-reaching consequences).

Thank you.

For what it is worth systems that are already in place often dictate how people wish to continue to work such that they don't by instituting a new system CREATE legacy data. Others decided they need to make a clean break that differentiates because the older systems are too cumbersome.

I work 100% in the Master Model Concept and I don't include drawing revisions or anything that even looks like being confused with a drawing revision in my model filenames. I use the Military versioning system throughout and recommend it to everyone who'll listen. That said there is nothing wrong if by convention you include a revision letter in your drawing file name, even if it is ignored by the versioning rules. In fact I have worked that way in the past and found that it works fine.

Conversely if you apply an alphabetic system that looks like a drawing revision number to your file naming system as a "part name version" in native then you are forced to use that same system for model. The effect of that within office cultures is that some people strive officiously to keep the revisions aligned even when told that it isn't a requirement or intent of the system.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

Hudson,
You mention you use the Military versioning system. Can you give any references or briefly explain how you decide what merits a x.1 vs x.1.1 or x.1.1.1 version? I think I'm starting to see the sense in using Military versioning for the actual solid models and Letter revisions for the drawings; keeping them separate. But I'd like more info on how to decide how many "dot" levels to use, and what drives which level is incremented.
Thanks.

Okay well I use part123.1.prt for a release, when I'm working on files between releases then I go part123.1.1.prt
Obviously the next full release is part123.2.prt

Brand new unreleased versions of an initial design may be part123.0.1.prt, part123.0.2.prt etc in native.

The main use I have made of the point releases is that when working in teams on the same project apart from needing an increment that works you need to stop different users from overwriting one another's work. In windows we do that be establishing a common working directory located on a server with CREATOR OWNER read/write access enabled.

You will notice among software releases that the system goes further, and example would be program123.1.1.1 and versioning rules would theoretically support multiple levels. However working with users according to what is basically a procedure I have never wanted to overdo the whole extreme complexity angle!

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum