Windchill "Name" becomes same as filename / number - any way around that?

[psobejko]

Calling all Windchill experts:

Can you help me out with this issue that has been irking me for a while:

In our current system, when making a new model, the CAD users are used to rigorously filling out the Name (as per company numbering scheme) but they leave the "Common Name" blank:

So then the hidden model parameter PTC_COMMON_NAME takes on the value of filename, that is, "Name" in the above dialog box.

Then upon saving to workspace, the Windchill "Name" of the object takes on the value of PTC_COMMON_NAME and so becomes the same as filename.  When object is uploaded to the server, our Windchill auto-assigns it the number that is the same as the filename.  So now, when browsing our database, I often end up looking at tables that have 2 or 3 columns filled with the same information: File Name = 995-13004.prt; Number = 995-13004.PRT; Name = 995-13004.prt.

Ok, so in our drawing title blocks and BOM tables, the "Part Name" field displays the value of the model parameter PART_NAME.

Well, I thought I would be clever and add the relation PART_NAME = PTC_COMMON_NAME to our start part.  Well, many engineers don't like it, and I think they have a good reason.  They are used to deciding what the part is called when the drawing is being completed; at that time, the value of the PART_NAME model parameter can be conveniently changed by double-clicking on the table cell.  With that model relation in place, double-clicking on the drawing's table cell now produces the message "User parameter PART_NAME in 995-13004 is driven by relation  PART_NAME=PTC_COMMON_NAME".  So now, what used to take them a couple of seconds turns into a minute-or-two ordeal (you have to go to Windchill, rename the object, refresh the workspace, regenerate the model and the drawing).  I can see it can be a real pain IF you didn't plan ahead...

Anyway, I don't really want to change their workflow, but I was wondering if there is a way for the Windchill object's Name to be changed/updated upon check-in? (specifically, is there a way that the object's Name is made equal to a designated parameter PART_NAME)?

[MikeLockwood]

Not sure if I qualify as a "Windchill expert" but I've been looking at and struggling with this exact topic for a long time.  Note that It's also complicated by many related preferences, and by related WTParts and you may want to expand your question to include them.

It's baffling to users that the words "Name" and "Common Name" in CAD are not evident on how they map to CAD Doc "Number" and "Name," with Filename mostly hidden.

It's also baffling to me that users frequently ask how to ensure the opposite - that Number and Name match (we have that unfortunate situation at Edwards).

Looking forward to comments from others.

[bsindelar]

While I can't comment particularly about the "name change/update on check-in", which sounds very much like a customization, I can offer you another option:

My company has a mass rename tool that runs very simply from the Windchill application server.  The input is a simple CSV where you identify the current EPMDocument number (or WTPart), and then supply any and/or all of the desired "new number", "new name", and "new filename" parameters - just separated by commas.  You identify everything up front, and a simple Windchill shell command executes the tool.

While it doesn't address the rename at creation time of the object, if you have a lot of CURRENT objects that need renaming you can do this pretty swiftly with this tool.  It uses all Windchill APIs and has been tested and confirmed working with Windchill 10.2 (and of course we can retest to your specific Windchill version and MOR if desired).  You could use this tool in conjunction with a Windchill report to export all CAD where any 2 or all 3 of number, name, and filename are identical and then use that report to make your corrections.

Please let me know if you're interested via e-mail at robert.sindelar@eccellent.com and I'd be happy to discuss this with you in further detail.

[dschenken]

I thought PTC_COMMON_NAME is able to be changed from the drawing by editing it; it's just a problem for WC Filename (needs to be unique) and Number (needs to be unique) Since any number of parts can have identical PTC_COMMON_NAMES, I don't see how it would work to back-drive items that must be unique. I also don't see why the PART_NAME intermediary is in place; what is it intended to add?

If one was to allow back-driving the data which Windchill uses to distinguish items it seems like a condition could occur where the rename would fail and prevent checking in because the name is already used, which means managing yet another error condition or having a layer of software to verify that this can't happen, which has its own problems. (I've read too many of Raymond Chen's Old New Thing.)

I'd try to work out why the engineers are unable to change the name or select the right name at a point in their work that doesn't cause them to take a hit. The coffee isn't going to drink itself, so waiting for the name change to percolate through is covered.

[psobejko]

I guess this whole PART_NAME is legacy issue - maybe from Pro/Intralink days before my time?  I will try the solution in which our standard title block will have &PTC_COMMON_NAME in the "Part Name" box instead of that designated &PART_NAME model parameter.

Still, I think one problem will remain:

Once the part is saved and uploaded to the server, its parameter PTC_COMMON_NAME is no longer editable (double-clicking a table cell that contains &PTC_COMMON_NAME results in the familiar prompt to "Enter value for PTC_COMMON_NAME", but entering a different value brings a rather unhelpful error message in the status bar "ERROR: Relation has an error. Please re-enter:")  I am guessing that is actually because the PTC_COMMON_NAME parameter became locked by Windchill.

Anyway, I was not looking to back-drive the WC filename or WC Number - those need to be unique.  But I don't see why, in principle, WC Name can't be changed from the Creo side.

In my opinion, what should happen is that PTC_COMMON_NAME remains editable; if it's changed, then upon check-in, Windchill renames the WC Name of the CAD object.

[dschenken]

I'd look at keeping PART_NAME and dropping the relation; then run a report from time to time and see which items have a part name that doesn't match the PTC_COMMON_NAME and batching those changes on Windchill, say, once a week or every night.

I am pretty sure this worked with Creo 2 and WC9.x; using Creo 3 and WC 10.x is the first time I recall that relation failure message. OTOH, I usually just change it in WC and Update, et al, so maybe I didn't trigger the message.