NX10 Interpart Expressions Broken? 3

[alj722]

It could be that I simply don't understand how to use the new NX10 interpart expressions since I just started using NX10, but from the cheap seats it appears that they taken away some extremely useful functionality. GTAC indicated that they are in the process of improving it but it isn't done yet and the current half-baked implementation is not very useful for those of us who heavily rely on manually creating and editing interpart expressions. Cutting, Pasting and manually editing the text portion of interpart expression formulas has gone away and replaced by hidden and locked equations. My current work-around to fix this "improvement" is to export expressions to a file, then create an set of interpart expressions in Notepad and cut and paste those into the expressions form. All this just to get back to what I had in NX9. Is anyone aware of any switch or setting to get NX10 interpart expressions to be editable again? I would be curious if others are finding this new expressions paradigm useful.

Drew

 

[TaylorAnderson]

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)

 

[alj722]

Wow Taylor! You get the prize for the most complete answer on Eng-Tips ever! Thanks.

I am really sorry to see simple text editing of interpart expressions go away, although I can understand the problem you were faced with. Manual access to the inner guts of the data is always useful. We are in NX native (our NX10 is native, although our NX8 is in TC) and manually edit those linked expressions has allowed me to do all sorts of useful things. I used that almost daily, until NX10. My current work-around in NX10 to regain that functionality is: Export an expressions file, creating a notepad list of the old text style interpart expressions and then cutting and pasting back into the expressions. It is clunky but seems to work (please let me know if I'm going to break something doing that). Now that I understand how the new expressions are working, I can probably adapt.

By any chance will the new expressions editor form allow for edits to multiple expressions at the same time? In IDEAS we had the ability to select any number of expressions and set them all equal to a single expression in one action (for example selecting 20 different dimensions and setting them all to a single expression). I can't count the number of times I've wished to have that capability back.

Thanks for all the info,

Drew

 

[TaylorAnderson]

By any chance will the new expressions editor form allow for edits to multiple expressions at the same time?

Actually, it does. And much more.

Again, I think you're going to like it.

I'm geniunely curious about the workflows in which you're manually editing multiple IPEs to do things... Might you be willing to contact me privately and describe those to me?

My email is just.what you would expect for someone with my name "at" siemens.com. ;-)

Thanks, Drew!

Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)