MFDO --
Finally saw this thread, and since Toost asked for me to chime in... ;-)
There's no difference in the update behavior of the models in which expressions have been renamed, versus models in which the pXXX expressions reference user expressions. They both work identically, and there are pluses and minuses to each approach.
I don't have any first-hand knowledge of how the PDW parts you reference were created, but guessing based on what's there, I suspect that the basic parameters may have been prepared ahead of time and imported all at once, creating a bunch of consistent "User Expressions" up front to reference while modeling. This is a somewhat common technique when building a bunch of similar parts, or modular parts, when very consistent expression names are of primary importance.
Renaming the expressions directly certainly also works. The challenge is that these expressions are linked to the features that they drive, and that introduces some interesting behaviors when those features are deleted.
Generally speaking, when a feature is deleted, the expressions associated with that feature are cleaned up (deleted) as well,
UNLESS those expressions are being referenced by other expressions, in which case the referenced expressions (only) are automatically preserved. But if, for instance, you had started a model with a nice sketch like this:
...and you'd gone to the trouble of naming all of the sketch expressions directly, as shown above, then you'd end up with a super-clean expressions list like this:
...and that looks awesome. For now.
Then, say you'd extruded that sketch, and in the process, had referenced the "height" expression in the End Distance expression (p6, here) of the Extrude feature:
Then you'd see that referencing relationship in the Expressions dialog like this, of course:
Now... Someday down the road, if you (or someone else) decides to create a different sketch here, like so:
...and reparent the Extrude feature to reference the second sketch, like this:
...and then delete the first sketch, then despite the fact that the Extrude is no longer referencing the first sketch, you'll actually still get the usual warning message about downstream effects:
...because that "height" expression (which is closely associated with the first sketch because the original sketch expression was renamed directly) is still being referenced by the Extrude feature. When you go ahead and choose OK here, the first sketch is deleted, along with
ALMOST all of its expressions -- except "height", which was still being referenced by the Extrude. This leaves the Expressions list like this:
Now, there are a couple of choices lurking in here, as you probably see now:
[ul]
[li]We think it's good to clean up feature expressions when we delete features. (So we generally do.)[/li]
[li]But we also think it's important to preserve that referenced expression. (So we have, obviously.)[/li]
[li]Those other named expressions may or may not still be relevant, but we don't know. (You've gone to the trouble of renaming them, but at the same time, you've not gone to the trouble of actually referencing them anywhere yet. So [for 20 years or so] we've chosen to go ahead and clean them up for you.)[/li]
[/ul]
SO...
If those named expressions are important to you, it might make sense to create them as "user expressions" first (created directly, independent of any feature, either manually or by importing them) and then reference those user expressions. That way, they'll be sure to stick around until you manually delete them, and you won't find yourself trying to figure out which named expressions will be preserved and which will be deleted when a feature needs to go.
But you can choose how you want to work.
For what it's worth, we've taken this one step further in features other than sketches. While in most other feature dialogs, you can actually enter an expression name like this to create a new named expression:
And when you do that, we'll actually do this for you automatically:
For what it's worth.
Does that help a bit?
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
3=80
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-00-49.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-01-41.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-02-39.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-02-53.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-05-20.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-07-54.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-08-15.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-08-25.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-37-42.png[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-11-28_16-38-16.png[/URL])
![[thumbsup]](/data/assets/smilies/thumbsup.gif "[thumbsup] [thumbsup]")
