I did a search in the NX6 doc and found it in "file name definition" in customer defaults - it mentions what options are available after the name exceeds 32 characters.
Simple search in NX documentation for File Specification comes up with this:
NX limits the maximum length of a filename or a directory name to 128 characters. For files, the limit of 128 characters is for both the name and the extension. The extension is always three characters, and must conform to the conventions specified in the section, File Types and Extensions. The period between the filename and the extension counts as a character, which leaves a total of 124 characters for the filename itself.
The full file specification cannot exceed 256 characters, however some functions require even shorter file specifications. Refer to the appropriate NX documentation to determine the proper file specification. As an example, interpart expressions are limited to a total of 128 characters, so the longer the part name is, the less room you have for the expression itself.
But I think Teamcenter is shorter or can be set to limit them to shorter. We spent 4 hours in a corporate meeting one day just discussing what limits to put on CAD file names and a define a corporate structure to the names.
"Wildfires are dangerous, hard to control, and economically catastrophic."
You should refer to ASME Y14.100 spec (see section 6.2.1 and 6.6). The spec mentions 15 and 32 characters. My preference would be to keep ID numbers to a minimum. The reason is that many applications have limitations on the character count for this field. It may not have any effect on the programs that you use, but it can cause issues when dealing with vendors which may not have an up-to-date programs. Of less importance is the item description, whereas it will be truncated or just cut off. Not a big deal because most systems track by P/N (ID).
You can use item parameters (attributes) which can contain other useful info.
This method was popular when the CAD tools did not utilize a pdm program to manage data. There were no common file storage areas (each assy and its components resided in a single folder). Also, the CAD tool really had no means to efficiently export a parts list, so there was no benefit to proper file naming. Users would name the parts whatever helped them navigate the assembly. Unfortunately, the problem arose when it was time to move this legacy data into a pdm tool. The files needed to have unique p/n's. Still, many CAD tools had not yet adopted the use of attributes and parameters useful to navigate assemblies efficiently. Users just appended a unique number to their custom file name (ex: front_panel_123456.prt or johns_cover_123456.prt).
Some prefer to use non-intelligent part numbers (123456-1.prt), but I prefer the use of a commodity prefix (10-123456-1.prt). The prefix can be useful for downstream legacy applications which have sorting capabilities. The prefix would identify something like a purchased electrical component, a machined part, a sheetmetal part, an assembly, a special tool used, etc.
I have used many different part numbering systems, so if you have any questions just ask.
Ben is basically correct, the actual Part File Name can't exceed 128 characters and the full path can't exceed 256 characters.
That being said, there is a slight change coming in NX 7.5, where while the overall path name length is still limited to 256 characters, the Part File Name will now be able to be as long as 248 characters. This change is actually being done to accommodate TeamCenter (this does not mean that TeamCenter supports 248 character file names, just that the 'hashed' file names which TeamCenter manages under the covers could have names that long).
John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Thanks Mike, So one follow up question. With no PDM, is there a simple way by which you can put a part description in the model file (attribute or something) and then be able to search (interrogate a part file list) on descriptions outside of and within NX?
One method I have used is to write a GRIP (I know, out-dated) program that assigns the attributes in the file for other uses, like the drawing titleblock. As part of the program, write a line to a text file that contains the part number, description and any other relevant attribute data that you may want to search on. Examples would be: material, thickness (for sheetmetal parts), designers name, date created, etc.
"Wildfires are dangerous, hard to control, and economically catastrophic."
External program like Ben mentioned. I have never had the need to do this. You mentioned in your other post that you will be without a pdm tool for about a year or so. If this is the case, are you planning on using a temporary excel file to manage your part numbers (to pull your p/n's)? If so then you can just use that data in native excel or have someone write a program which can use and report on the data contained in the excel files. I have seen companies generate excel files for parts lists, and have the parts list revisions on a separate tab. Kind of old school, but make work in the short term.
Keep in mind, most databases are oracle based: The filename you select is not the filename that oracle stores it as. Your part number exists in the oracle database similar to how attributes (parameters) exist.
Actually there is a way of adding that sort of information to a part file's header and even read it without having to open the part file, but there are no built-in report mechanisms, at least not in native-NX, but you could write a simple GRIP program to do that in no time.
To add, and it turns out, to read that data, go to...
File -> Utilities -> Edit Other Part Header...
...and select a part file from the explorer and you will find that you can read or write a 132 character 'description'. This 'description' can also be read by a simple GRIP program.
Note that if you're interested in the file header for the current Work part, go instead to...
File -> Utilities -> Edit Work Part Header...
...where you will find basically the same dialog with the same options. Just remember that if you make a change to the Work Part header, you will still need to save the part file, whereas if you change a file on disk, the change is saved as soon as you hit the OK button on the dialog.
John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
There's another option here that might be of interest to some of you and that it that there is a SECOND area of the Part File header which you can store information in, and this is called the 'Customer Area'. Again, it's a 132 character field which can be written to and read from without having to open the part file. The difference between this and the 'Description' I talked about above, is that the 'Customer Area' can ONLY be accessed via NX Open programs (GRIP or UFUNC). It cannot be read interactively, only through a program, which provides an extra secure location for critical information that one might wish to add to their NX Part files.
Anyway, since I already mentioned the 'public' description area, I figured you might as well know about the 'secret' one as well ;-)
John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
There is however in my view only one sensible answer to this question. Keep the names as short as practicable.
Why would anyone want an 128 character file name let alone a list of such names to have to pick through in order to find the correct part. That to me is making a rod for your own back!
Hudson, have you ever seen the 'file names' which are generated by a simple 'hashing' scheme (as happens in managed systems like TeamCenter and others) where a large number of files are kept in a single flat-file?
John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Yes I have and I get the efficacy of it for databases etc, but as far as my perspective on interfacing with the user goes I stand by my comments.
One of the major bugbears of working with such databases of course is that you do need to bring more advanced storage technology to the solution in order to make things relatively manageable. It arrives at a situation where I couldn't suppose what might happen if we even tried to entertain old fashioned data backups to rebuild a database comprised of unidentifiable component files so patently not designed to be addressed directly by the users.
So I didn't mean to say that there are no conceivable uses for long filenames, just none that the user would do well to wish to have to interface with had they the choice to apply the KISS principle.
If you are on a windows system, I'll add one more option: file properties. If you right click a file and choose properties then the 'summary' tab, you can add information about the file that you can then display in windows explorer (using detailed view).
There is also a tab for adding custom properties, but I have not found a way to display those in windows explorer.
