Are other users encountering issues with the new format of Interpart Expressions in NX 10?
We use a lot of Interpart Expressions to drive our assemblies from the top down.
In NX10 Interpart Expressions are automatically allocated a P number so visually, when looking at the expression dialog with Interpart Expressions used, all you see now is P numbers. So when you trying to work out what is driving a size, the design intent is hidden until you put the mouse pointer directly on top of the P number.
NX10 only allows you to see one Interpart Expression at a time.
In NX9 you read an expression as a complete entity which is clearer.
Below is an example of an expression from an existing part;
NX10 Now Shows:
In NX10 to modify an Interpart Expression has become a multi-step process.
In NX9 you can directly modify the text, even changing the linked part name when copying a part from one assembly to another with the same ASM expressions, or copying sketches/features from one part to another.
We are currently submitting an ER.
How are other users finding working with the new Interpart Expression setup?
Do many of you use Interpart Expressions to drive your assemblies from the top down?
@TaylorAnderson put together a very detailed and informative post about this a few months ago over on the eng-tips forum.
The short version is: some necessary changes in Teamcenter drove changes to how the references are stored and displayed to the user. It sounds like they are working on ways to improve the workflow and presentation in future versions.
I'm sure that they will consider your ER, but I doubt that any significant changes will be made to NX 10 in any future MR's and MP's and due to architectural changes to the code, it certainly won't revert to the NX 9 workflow.
This was the biggest bummer I learned at the PLM World conference this spring. Even at the presentation on this topic Taylor Anderson seem to realize that this has some serios shortcomings. No idea if that will be reflected in any chnages.
I filed an ER right away after the conference. As expected no feedback since.
|7399493||OPENNR||[removed]||ER: Expression Links are not identifiable in NX 10.||DAN IORGA||05-jun-2015|
o Short Description: Expression Links are not identifiable in NX10. o What activity in your process is NX not able to currently handle? We need to be able to quickly and reliably identify which expressions in a base part are linked to other external parts via IPE. The new scheme implemented in NX10 break this requirement, as instead of: my_expr = "204523605"::Diameter which clearly tells me my expr "my_expr" in the base part is linked to an expression called "Diameter" in the external part "204523605". Now we have this intermediary created standard expression (I'll just call it p41) which breaks the visual communication of this being a IPE (these entries can be far apart, p41 could well be another expression in the base part): my_expr = p41 p41 = ˆ (Pls fill in how it looks in NX10) o Do you currently have a workaround? No. The entire visual access we had for conveying of this important fact - that an expression that is driven from completely different part - is now broken. o Do you have a proposal for the solution you envision UG providing for this capability? Among the possible solutions: 1. concatenate the part number that IPE is linked to this newly created expression (note the entire string after the "=" sign is just an expression name!! --> p41"204523605"::Diameter). Major advantage here is that the name of the part is showing my_expr = p41"204523605"::Diameter 2. flag the fact it's an IPE in some other way: my_expr = IPE::Diameter my_expr = IPE41 o What is the level of productivity gained from such an enhancement? High productivity would be gained. No additional research is required, the info is there for everyone to see and act upon.
I have read through Taylor Anderson's eng-tips post, I will be waiting to see/test the results from the changes he has discussed.
At this stage we will need to stay with NX9, because there is too much time invested in the creation of parametric models to switch at this time. Although the function of the NX10 interpart expressions (from the assembly down) still works the same as in NX9, we need efficient editing capabilities for the interpart expressions within the parts below.
It doesn't need to be the exact same workflow as in NX9, but it does need to clearly show design intent and to have quick editing options, not a multi-step process.
Dan, have you read through the post on EngTips yet?
I was listening closely at PLM World, and several of the group's suggestions have been implemented, including some automatic naming of the newly created IPEs to better communicate the original expresion name, and the optional ability (controlled by a customer default) to automatically add either a prefix or a suffix to better identify expressions within formulas as an IPE.
Both of these, including screenshots, are described in the EngTips post above, BTW.
Believe it or not, we're paying very close attention to these ERs, even if we can't personally reply to every one of them. I appreciate your feedback, both at the conference and in your ER. Thanks!
You'll be pleased to know that starting in 10.0.3, editing an IPE is as simple with a new MB3 command Edit Single Interpart Expression that is available when you right-click on any "blue" interpart expression:
This basically launches you right into the familiar Create Single Interpart Expression workflow, where you can just pick a new parent part and/or new parent expresion. QED. In most cases, this is even easier (and certainly less error-prone) than direct text editing of the expression formula.
And in NX 11, we've built this behavior into the "Edit..." right at the top, to make it even easier:
And of course, if you need to redirect all of the IPEs that are currently referring to a particular parent part and poitn them all at a new parent part (all in one operation, with zero manual editing) the Edit Multiple Interpart Expressions command is still available in the drop-down menu at the bottom of the Expressions dialog as well.
We've been paying very close attention here, and moving quickly. I think you'll like what you find. Thanks for your help, and please keep the feedback coming, either here or privately.
I have seen the Edit Single Interpart Expression option but to get to that takes a few steps.
In the Expressions Dialog below, visually you cannot tell which are Interpart Expressions. It is not until you select one and then put your pointer on the exact P number that it flashes up the details.
Now for the example of an expression from an existing part I had earlier
If I come across this I can see that these are Interpart Expressions, and I can read through it to work out what is going on.
For NX10 this became:
This does guide the user to what they actually are, Interpart Expressions.
Could it be something like this (With the P numbers blue):
I would also see that ideally from that P number you could right click a pull down the Edit Single Interpart Expression option. This would be ideal in to ways;
1) You don't have to go looking for the P number in a potentially big list (although you can filter)
2) If you have accessed the expression dialog from within a Feature, you cannot just scroll down the list to edit it you have to back out and go into the expressions dialog separately.
>> Could it be something like this (With the P numbers blue):
To be completely honest, if we could do that, then we just wouldn't have changed Interpart Expressions at all in the first place. :-)
I'm copying and pasting from the EngTips thread here for the benefit of anyone trying to follow this, but think back to the original problem that started this:
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...
>>In the Expressions Dialog below, visually you cannot tell which are Interpart Expressions.
That's correct. (In NX 10.0.0.) I heard that feedback loud and clear at PLM World. And that is why, as I've described in the other thread, we're trying to be smarter about how we name the new "blue" IPEs in NX 10.0.3 and NX 11, automatically reusing 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:
We couldn't add the new NX 11 customer defaults to NX 10.0.3, and so we had to add this new behavior to NX 10.0.3 using environment variables. To replicate the "naming + suffix" behavior in the images above, you'd set:
(And for the record, UGII_KF_PREFIX_SOURCE_IPE_NAMES is also available in NX 10, if you want to use a prefix instead. There are pluses and minuses to both, of course.)
And so if you set these variables, the first time you open an NX 9 part containing your big expression in NX 10.0.3, this big guy:
...would turn into:
BlowCavity_OverallHeight_IPE - BlowBase_Stroke_IPE - BlowBase_CarrierPlate_Thick_IPE - BlowBase_BodyHeight_IPE - 3
...which is actually pretty darn readable, and pretty darn comprehensible, and it's quite clear which elements in the formula are IPEs.
Wouldn't you agree that's a whole lot better than the p-values? :-)
>> I have seen the Edit Single Interpart Expression option but to get to that takes a few steps.
The old workflow for basic editing of an IPE would have been:
1. click on the expression in the list above to put it into edit mode
2. go find the exact correct spot in the formula string and either:
3a. Click there and start backspacing or
3b. Click and drag there to highlight the exact portion of the filename you want to change and
4. Type in a new filename (being careful not to make a mistake.)
The new workflow would be:
1. MB3 on the expression in the table
2. Select "Edit Single Interpart Expression" from the menu
3. Choose a new part
4. Choose a new expression
Time-wise, we think they're going to be VERY similar. Once involves typing and backspacing or highlighting and deleting and the potential for typos and invalid formulas. The other creates the perfect formula for you from a few clicks. They're definitely different -- that's for sure. And I completely understand that's going to take some getting used to. But for a whole bunch of cases, this may actually be faster and will almost certainly be more reliable.
Now, with that said... :-)
Your two workflows at the end are really good. The idea of being able to MB3-Edit an IPE directly from inside a second formula is a pretty cool workflow. We don't really do that today anywhere in NX today, so it's not something we can throw in there easily, but it's definitely something we can investigate. (No promises today, of course.) And yes, that would also be very useful in the "edit from a feature" workflow, too.
Thanks again for your feedback and comments, Geoff. Exchanges like this make our tools better, and I really appreciate your help with that.