Drew --
Thanks for your post.
This is an important topic. I actually did a roundtable discussion at PLM World this year about some upcoming NX 11 changes to the expressions dialog (and those who attended NX 11 beta testing saw this there, too), and about the NX 10 Interpart Expressions changes specifically. We got a bunch of great feedback, and we've made some adjustments that you'll see coming very soon.
Interpart Expressions (IPEs) were in fact changed in NX 10, in two different ways. One of these we planned for. The other was a more sudden change to which we had to react somewhat quickly.
Preserving "Broken" Interpart Expressions
The change that we planned (an executed) was one to make broken IPEs behave more like broken WAVE interpart geometry links. Prior to NX 10, there were certain circumstances (when a parent expression had been deleted, or a parent component had been deleted from a common assembly context) in which IPEs would be removed entirely, and the expression containing the IPE reference would be reverted to a constant value:
You might have seen this happen before, with this message:
Of course, when we did this, we were actually destroying a piece of the design intent contained in that interpart reference.
And so while at one point years ago we had decided that was the best option, we recently decided that we could do better.
And so starting with NX 10, we will preserve the IPE reference, and leave the IPE in a "broken" state that preserves the design intent embodied in the IPE. And when we encounter one of these broken references on load, we'll warn you with a similar dialog containing this message instead:
[pre]"The interpart expression references will be preserved, and relinked when the expression is available."[/pre]
And we'll put the IPE into a new "Broken" state:
And when you either recreate the parent expression, or load the parent part containing the parent expression, we'll automatically re-link the broken IPE (and let you know that we've done that for you.)
And the last known-good value will be preserved in the meantime, of course.
Overall, we think this does a better job of preserving the work you've put into creating Interpart Expressions, and provides for some interesting new ways of dealing with template parts and assemblies that doesn't involve manually recreating broken IPEs. We hope you like this one.
Modernizing the Interpart Expression Architecture
This is the change that in all honesty took us by surprise. During the NX 10 development cycle, we were informed that Teamcenter had made a very fundamental change to their architecture, and that as a result, the Item ID would no longer be a reliably unique identifier. This change is called "Multi-Field Key", or "MFK", and frankly, you'll need to get someone from Teamcenter to describe why this was a necessary change. It's been a struggle for us to react to this deep change, and the OTHER change in Interpart Expressions came as a direct result of this foundational shift.
As you know, prior to NX 10, Interpart Expressions used a text string in the Expression formula to store the interpart reference. In managed mode, this reference used the Teamcenter Item ID, and the uniqueness of this Item ID made this IPE reliably unique as well. But along with the advent of MFK came the possibility that this Item ID would not be unique, and that IPEs could become confused in cases where multiple parts with the same Item ID were present in the same NX session. And so we needed to use something other than the Item ID to refer uniquely to parent parts in this context.
Under MFK, there
is a unique identifier available, but this identifier is really long and is not human-readable. Replacing the Item ID references with this new identifier would have exploded the length of expression formulas containing interpart references, and would have made them very difficult to work with. (And for certain customers with very long expression formulas already, this would have broken them entirely.) Readability of expression formulas would be seriously impacted. Users would struggle greatly to comprehend relationships between parts referencing these strings.
We looked at several alternatives here, and agonized over the tradeoffs. And in the end, we chose to implement a method that would super-reliably preserve the interpart relationships that you've already created, and leave expression formulas in a reliably concise state. And the major constraint, of course, was that we couldn't just use the text in the expression formula to store the interpart reference anymore...
Starting with NX 10, Interpart Expressions are stored as a "blue" system expression, and that nasty unique identifier is stored internally and not exposed to NX users. (You're welcome for that. It's ugly.) The "source"::expression syntax now displayed is for historical familiarity only, and is not actually used to store the Interpart Reference anymore. Display-wise, this brings Interpart Expressions into alignment with Attribute References and Measurement Expressions, each of which are similarly driven by an "external" parent.
Because we can no longer use the interpart reference text in expression formulas, we will automatically do a couple of things to bring all pre-NX10 parts up into the modern state. When pre-NX10 parts are loaded into an NX 10 session:
[ol 1]
[li]We will automatically find all textual interpart references in expression formulas and create one new "blue" Interpart Expression for each unique reference.
(We will not create multiple Interpart Expressions referencing the same parent expression in the same parent part.)[/li]
[li]We will automatically replace all textual interpart reference in expression formulas (the "source"::expression syntax bits) with a simple reference to the new blue "system" IPEs created in the previous step.[/li]
[li]And to be very clear,
all original expression names and values in the target part are preserved intact after this conversion.[/li]
[/ol]
And so, for a set of expressions like this in NX 9:
The automatic NX 10.0.0 conversion would look like this:
In the end, this turns out to be a super-reliable way to bring all legacy IPEs "up-to-date" without breaking associativity. Of course, the tradeoff here is that it creates some new expressions and a new level of indirection that wasn't necessarily there before. (Depending on how you created IPEs before, you may have already had an intentional level of indirection here already.)
Now, in NX 10.0.3 and in NX 11, we're closing some gaps that we hadn't anticipated when we originally implemented these changes in NX 10.0.0:
[ol 2]
[li]We're trying to be smarter about how we name the new "blue" IPEs, borrowing the name of the source expression where possible, and giving you a way to optionally include a suffix or prefix to these, if you like, to make it easier to recognize them as IPEs when they're used in other formulas:
[/li]
[li]
And to your specific question, Drew... With the loss of the ability to just edit the textual reference in the formula to redirect an IPE to a new parent, we're introducing a new UI for editing an IPE. It will be familiar, and as you'd expect, it will be as simple as choosing a new parent part and parent expression from within that part. In the meantime, a workflow in which you create a new "blue" IPE and then edit or replace references will be necessary until 10.0.3 or NX 11. Does that make sense?[/li]
[/ol]
And so the automatic conversion in NX 11 (and NX 10.0.3) looks more like this:
...or if you're using an "_ipe" suffix, for instance, like this:
[And yes, if you're paying attention, that's a little sneak peek of one part of the new NX 11 Expressions Dialog.
]
And so that's a nutshell summary of the two new changes in NX 10. (There are plenty of smaller implementation details, as you'd expect.)
Again, huge thanks to those of you who attended my roundtable session at PLM World and gave us some good advice and direction there. I hope it's evident that we've listened to you and adjusted several things accordingly.
And please feel free to contact me (publicly or privately) if you still have concerns. We recognize that this is a significant change, and that in the short-term, it introduces some new complexity. But again, given the reality that the existing syntax would not be reliable going forward, we think we've done this in a way that best preserves the investments you've made in parametric, associative interpart models. And again,
all original expression names and values in the target part are preserved intact after this conversion.
Questions?
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
