How are you using the Common Name attribute?

[ptc-683722]

I am looking into the Common Name attribute and the possibility of using it in my company. I would like to hear from those of you who are using the Common Name attribute and what set of variables you are using. Has anyone made it manditory for users to use this attribute. Taken it one step farther and checked for a matching variable when checking objects in?

[amansfield]

We have started to use the Common Name as it solves a number of issues that we were facing, the main one being that it was nearly impossible to know what you were looking at in Windchill using basic search.

We had been exposing an internal Pro/E parameter mapped to an Windchill attribute (carried over from Intralink 3.x) but it was inconsistently used, was only in part and assembly models (not drawings) and could only be found using Advanced Search. The best thing about Common Name is that it's a consistent way of identifying things, is available for ALL types of CAD files by default and is part of basic search.

Our CAD file naming scheme uses part numbers or project numbers as the filename:we have been trying to discourage users from naming development files with filenames that use words in them like "ball_bearing.prt" or something like that. The main reason is to ensure uniqueness across the system and this is where the Windchill Name (Common Name) is very useful, as it doesn't have to be unique: only the NUMBER and filename have to be. Since the Name is always visible it becomes the way that one can tell what an object is, rather than using the filename to convey that information. Also since filenames have to be unique you can't use filenames more than once for similar objects.

Our CAD model OIR currently sets Name=NUMBER=filename, unless the Common Name is filled in when creating a new file: then it's just NUMBER=filename. I believe this is pretty common practice.

The biggest hurdle I've had in doing this is trying to get the users to understand the difference between Pro/E and Windchill terms. This is a royal pain. Eyes glaze over when you say that "Name" in Pro/Engineer is equivalent to "filename" in Windchill, Common Name in Pro/Engineer is equivalent to "Name" in Windchill, and that NUMBER in Windchill isapplied by the system. (Mention "Object Initialization Rules" to most of my colleagues andyou've lost them immediately :-)).

Object identity becomes very important as the data set grows, the CAD user base changes and the system begins to be used by non-CAD users. We had never documented any guidelines for naming CAD models and we realized that we needed to do this so that the objects would be classified consistently. We have been renaming legacy objects during the revision process (and related objects too) as well as enforcing use on new objects, to bring the Common Name into day to day use: it's a huge task and will take a long time to complete, but it'll be worth it in the end. I've already had positive feedback about it.

My biggest regret is not recognizing what value Common Name had as we could have started using it many years ago in Intralink 3.x.

[MikeLockwood]

Please see attached.
Huge confusion due to the labels used on the Create screen in Pro/E (Creo), but actually pretty straight-forward to work with. This diagram should be front and center in PTC documentation.

Many people chop off huge efficiency by setting the Name, Number and Filename the same. Should have the Number be a number (unique) and the Name be descriptive words.

[patrick.chin1]

In my past implementation with the help of www.Najanaja.com, we used ProE Common Name to be mapped to Windchill Name/Title. See attached email. I've been doing this since the first implementation of Windchill PDMLink 6.2.6. That way Windchill OOTB searches for Number, Name looks like a BOM report and don't need extra entries of duplicated IBAs and ProE parameters.

[ptc-5248439]

Agreed. However, wouldn't it be nice if PTC made the following enhancements:


1. Have an option in the ProE model tree to display Common Name instead of filename in the first column. (I know you can add it as an additional column.)

2. Have a better, more intelligent way to text wrap Common Name in a format table. Typically, we have a two line drawing title which concatenated together would be the Common Name. But I am not sure that I can drive Common Name by a relation, and I don't know an effective way to wrap the value of Common Name in a format table (ProE treats the value of a parameter as a single word even if there are more than one word in the string.)


From: Lockwood,Mike,IRVINE,R&D [

[amansfield]

I should have mentioned that we now use PTC_COMMON_NAME:D as the main drawing title, sowe use the Common Name as the descriptive term in both Windchill and on drawing formats. We still use a parameter /attribute to track the product group name: this is something that would be useful as a system level attribute.

I agree with Mike about the best way to use Name / NUMBER / filename, however, with a tried and true legacy numbering scheme and15+years worth of CAD data, autonumbering isn't an option for us at this point. It would require a level of customization that we can't implement at this time. I'd love to have the system automatically generate both project numbers and released part numbers, but that's science fiction for us at this time.

[JosephCugini]

I am working through an Intralink 3.4 to 9.1 (10.0) migration and would
like to take the time to address a number of bad practices that I
inherited with the original implementation of Intralink 3.x. Primarily,
the release and CAD part naming process. Our site is currently document
centric and we have a Teamcenter implementation for the CM control of
drawings. As for the CAD objects we utilize as-stored configurations
stored Intralink. Our CAD part naming convention is a butchered
combination of part numbers and descriptions while our drawings follow
our internal numeric convention.



Going forward, I would like to enforce the use of "COMMON_NAME" for the
part description and have the ProE part name = the part number. The
issue of course is what to do with special characters. Mil standard
hardware for example shows up on the PL with "/" in the file name. I
would imagine the immediate solution would be to designate a parameter
on the CAD object called "part_number" and make it a string variable.
While that solves the issue of having special characters in the part
number, it doesn't prevent users from creating duplicate parts in the
database with the same part number and thus making it extremely
difficult to CM/revision control the models.



Can anyone offer insight on how to handle special characters in part
names or how to make a designated parameter in 9.1 a key field so that
the system ensures it is unique prior to a check-in.



Thanks,
Joe

[DonSenchuk]

In one of my previous positions, we attempted to follow the MIL standard for naming files. We were provided rules by the Army to be used in conjunction with the MIL spec. In all cases where special characters showed up that could not be used in the File Name or Number within Windchill, an underscore was implemented instead. This basically boiled down to all special characters except underscores and dashes being converted into an underscore.

The parameters showing it on title blocks and such were not tied to the Windchill attributes Number or File Name. It was left up to the individual to make sure they matched.

Then it was simply a matter of teaching the user base to properly fill in Name when creating a new Pro/E file.Common Name was used as a description/nomenclature with some wicked relations to parse it into three lines for the title block.

(Some time ago I posted the relations on the boards and a PTC rep came on to let us all know line wrapping for a single parameter was planned forWF5. Not sure if it made it in after the rebranding toCreo.)

In Reply to Joseph Cugini:

I am working through an Intralink 3.4 to 9.1 (10.0) migration and would
like to take the time to address a number of bad practices that I
inherited with the original implementation of Intralink 3.x. Primarily,
the release and CAD part naming process. Our site is currently document
centric and we have a Teamcenter implementation for the CM control of
drawings. As for the CAD objects we utilize as-stored configurations
stored Intralink. Our CAD part naming convention is a butchered
combination of part numbers and descriptions while our drawings follow
our internal numeric convention.



Going forward, I would like to enforce the use of "COMMON_NAME" for the
part description and have the ProE part name = the part number. The
issue of course is what to do with special characters. Mil standard
hardware for example shows up on the PL with "/" in the file name. I
would imagine the immediate solution would be to designate a parameter
on the CAD object called "part_number" and make it a string variable.
While that solves the issue of having special characters in the part
number, it doesn't prevent users from creating duplicate parts in the
database with the same part number and thus making it extremely
difficult to CM/revision control the models.



Can anyone offer insight on how to handle special characters in part
names or how to make a designated parameter in 9.1 a key field so that
the system ensures it is unique prior to a check-in.



Thanks,
Joe

[JosephCugini]

Don,

Let me first off thank you for replying to my e-mail. I have considered
what you implemented but was concerned with the change management
consequences if a user had two ProE parts (both with the same part
number parameter). For example, I am looking for a way to prevent a
user from duplicating a part to implement a change but leaving the part
number parameter the same as the original, thus having two different
ProE files describing the same part. I believe the correct solution
should be to revise the formally released part, follow your sites
release procedures and request to promote the new revision so that you
have accurate configuration management and revision history.



Another reason I'd like to control this is to prevent the inadvertent
change of library objects. There is nothing worse than going through
the effort of setting up a dedicated library, verifying it and locking
it down only to find that users can just duplicate the parts and put
them in an area where they have check-in rights. Unless you can enforce
the uniqueness of a part_number parameter you will always have
difficulty ensuring the configuration of the parts that make up the BOM.




Ultimately our goal is to automate the creation BOM's out of Proe,
release product structure into PDMLink and tie in configuration control
to the models.

[MikeLockwood]

Keep in mind all of the following:

1. Plan on using WTParts at some point, to represent the Part. The Number and Name on this object need to match what is labeled on a cardboard box of 50 ea in the warehouse and in the inventory record. The Number is enforced by the system to be unique. Applies for both components and assemblies. Work FROM "this is the part number that company deals with" TO "this is the engineering documentation that defines that part."

2. Plan on associating all CAD Documents to the WTPart for that item. Link types are important.

3. Each CAD Document has 3 key attributes: CAD Document Number, CAD Document Name, filename. These are mapped from the two entries made during creation in CAD (or if creating a CAD Doc directly as a workspace function). CAD Document Number is enforced to be unique by the system. Filenames do not have to be unique.

4. Plan for "tabulated" drawings, in which many Parts are defined on and mapped to a single Drawing. Plan for Change Management on these.

5. Fill in the Drawing title block using system attributes as much as possible (CAD Document Number / Name). Show the primary model on the drawing, full Version (e.g. B.4). Attempt to do this directly using .FRM formulas, avoiding CAD relations.

[JosephCugini]

After working through this issue for the last couple days and reading
previous messages on the forum, the solution to the file naming
convention question jumped out at me. Again, my biggest issue was how
to handle special characters in CAD file names. I was fixated on using
a designated parameter from ProE for the part number but had concerns
maintaining uniqueness of parts. Ultimately I wanted a system that
could generate a BOM from CAD structure with the ability to tightly
integrate CM control of the CAD files (ie. limit the possibility of
duplicate parts).



The solution lies in turning off auto-numbering in the object
initialization rules. Once done, the user has the ability to rename the
Windchill number independent of the file name. With auto numbering left
enabled, the user can not rename the Windchill number field, it's grayed
out. Because the Windchill Number must be unique it would highlight
to a user if they were trying to create a previously revision controlled
part. This is also perfect because the Winchill Number allows special
characters and is used to generate BOM's. Bottom line, the system
enforces that both the number and file name must be unique. In the past
I never really understood the power of this until now.



With this in mind the use case for part numbering/naming would look
something like this:

1. Proe user creates new CAD geometry

a. User should attempt to name the ProE file exactly the same as
the part number to be displayed in the ERP system (if the OIR is
configured correctly the system will use this ProE file name to populate
the Number displayed in the PDM/Intralnk field).

b. If the part number is not known the user can enter any ProE file
name (the system enforce uniqueness)

c. If the part number contains special characters the user should
replace them with an underscore (special characters will be handled in
later step)

2. During ProE file creation use "Common Name" as the description
of the part

3. Save models in PDM Link/Intralink

4. Remember, OIR's are configured to populate the ProE file name
to the PDM/Intralnk number. Rename the number in PDM/Intralink for
those parts that the number was not known during initial creation or
that contained special characters.



Following the steps above and assuming you will be attempting to capture
a BOM from PDM/intrlaink you should have flexibility to name your ProE
files what you want, enter a separate description, and have a unique
parameter for capturing file names that would appear on a BOM. See
below for example screen shot.



Thank you again to all that sent me messages and helped contribute to
clearing this up.

[MikeFoster]

I'm curious if Number can be put in repeat regions on a drawing for the parts list? We use the repeat region parameter "&asm.mbr.name" which puts in the file name, upper-cased, minus the extension. Is there repeat region parameter for Number?

Thanks,

Mike Foster
ATK

[patrickchin2000]

If you are referring to the ProE/WGM PTC_COMMON_NAME, in my past implementations, we have mapped it to the ERP material description and the PLM Windchill System Name. We also applied some customization to behave like an IBA. So you can change the NAME like a BOM, and the name has history. The workaround for using the save as history doesn't cut it. We just want the default Product Structure and EPMDocument Structure to behave like a normal BOM. I thought it was a more refined solution than having the ProE file+extension appearing for Windchill NUMBER, NAME and FILENAME. Use the attriubutes what they were hopefully architected for. To have the behavior of Pro/I X3 is just redundant.