Renumber "P" expressions in NX10

[baschuve]

I have found a few other discussion threads that are similar, but not exactly what I am looking for.
One of our users is looking for a method (grip, journal, other) to 'renumber' all "p" expressions in a NX part file to remove gaps in numbering. Is this possible / practical?

Existing:
p0
p1
p2
p44
p356
p357
etc.

Desired:
p1
p2
p3
p4
p5
p6
etc.

Thank you.

 

[TaylorAnderson]

baschuve --

Really good question.

As SPLM, we've actively resisted providing a utility for this, because there are some pretty nasty side effects if the end user doesn't approach this perfectly.

The biggest opportunity for nasty problems here is interpart expressions. Interpart expressions (IPEs) are a pretty simple "pull" or "reference" relationship, where the "referencing" or "destination" part retains a reference to the "source" or "target" part, but not the other way around. As such, it's difficult to predict where expressions are being referenced unless all of the potential downstream referencing parts are open in the NX session. (And yes, if the referencing parts are open in the session, then we can very easily tell you whether an expression is being referenced or not.)

But it's pretty easy to get into a situation where you've got a source part open, with one (or some, or all) of the downstream parts containing IPEs that reference expressions in that source part NOT currently open. And in that situation, if you rename expressions in the source part, the downstream referencing parts will not know about that change.

And so the next time you open those downstream referencing parts, the IPEs there will still be looking for the old expression names.

...which may no longer be there, in which case the IPEs will be put into a "broken" state in NX 10+ (the last known good value cached, waiting to be directed to a new parent) or converted to a constant value (with the interpart reference deleted entirely) in versions prior to NX 10.

Or even worse, if you've started with a situation like this:

p1 <-- With an IPE "source":1 referencing this one
p2
p6 <-- With an IPE "source":6 referencing this one
p10 <-- With an IPE "source":10 referencing this one
p11
p23
p24
p25
p34
p68 <-- With an IPE "source":68 referencing this one
p74

...and you renumber the expressions without the downstream part open, then you would end up with:

p1 --> p1 <-- With an IPE "source":1 CORRECTLY still referencing this one
p2 --> p2
p6 --> p3
p10 --> p4
p11 --> p5
p23 --> p6 <-- With an IPE "source":6 referencing THE WRONG VALUE
p24 --> p7
p25 --> p8
p34 --> p9
p68 --> p10 <-- With an IPE "source":10 referencing THE WRONG VALUE
p74 --> p11
?? <-- With an IPE "source":68 now BROKEN

...which is all kinds of wrong. :-/

...and which would require some manual re-association of the broken IPEs to fix.

Presuming you remembered how all of the IPEs were hooked up before.

For all of the referencing parts.

[NOTE: One important lesson here is that giving important expressions a meaningful name is a really good idea.]

And so in the end we're SO wary of creating this problem in our customers' assemblies that we've actively chosen NOT to provide a utility to renumber expressions.

And so if you choose to pursue this with automation anyway, beware... There be monsters. ;-)

Does that make sense?

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

 

[JohnRBaker]

Years ago I wrote a GRIP program to do this and it would automatically ignore any potential duplicates, but it only worked for parts that did not have IPE's, as Taylor has pointed out. But if that was not an issue, it worked pretty good. The problem is that I no long have access to NX and so there's not way that I can help, but someone might still have the program floating around somewhere.

John R. Baker, P.E. (ret)
EX-Product 'Evangelist'
Irvine, CA
Siemens PLM:
UG/NX Museum:

The secret of life is not finding someone to live with
It's finding someone you can't live without

 

[PDW]

Dear all,

attached should be the GRIP program that Mr. Baker is talking about.
Unzip it to a desired location.
in NX: CTRL G and open the exetcutable .grx file.
It should do what you need, but on your own risk...

BR.

 

[JohnRBaker]

No, that's not the one I was thinking of, although it is one that I wrote. The one BR posted was intended to replace all of the 'hashed' expression names with plain ones (when you merged parts together, the expressions from the second part file were automatically 'hashed' so as to prevent any potential conflicts) and this program simply removed the 'hashing' if it didn't result in a duplicate.

John R. Baker, P.E. (ret)
EX-Product 'Evangelist'
Irvine, CA
Siemens PLM:
UG/NX Museum:

The secret of life is not finding someone to live with
It's finding someone you can't live without

 

[PrintScaffold]

By the way how come that in the complex parts NX quickly rakes p-numbers up to 5 and 6-digit numbers? Not very convenient.

http://www.cadroad.com

 

[JohnRBaker]

Many of the new complex functions which creates a lot of geometry based on complex formulas, sheet-metal features being just one example, computes a large number of variables only a few of which are exposed as 'parameters' associated with the feature being created. However, for internal consistency and to make sure that the code is easy to maintain, rather than create a totally separate scheme to store and manage those 'hidden' variables, NX just uses a single expression scheme, just that a large number of them are never exposed to the user yet they take-up so-called 'P' numbers. Granted, I think this has been overdone a bit and that reserving many of the 'P' numbers are unnecessary. I would suggest that you open PR's for those examples where it appears to be particularly excessive. The worst that can happen is that they will turn it into an ER but at least if enough people bring this up that they just might look into cleaning-up some this.

John R. Baker, P.E. (ret)
EX-Product 'Evangelist'
Irvine, CA
Siemens PLM:
UG/NX Museum:

The secret of life is not finding someone to live with
It's finding someone you can't live without

 

[TaylorAnderson]

The new hole feature is the easiest place to observe this behavior that John describes. There are a zillion options in the dialog, but only certain subsets of those options are valid in various configurations of the hole, depending on whether things like tolerances, threads, chamfers, etc. are included or not.

The "missing" or "skipped" expression numbers are essentially "saving a spot" for some of those options that are toggled off right now.

The new measurement feature in NX 12 will use this as well, for similar reasons: to preserve continuity as certain measurement expressions are turned on or off, including preserving the original "p" numbers if those same measurement expressions are toggled back on later.

That decision whether to go back and reuse p-numbers is actually a lot trickier than it looks at first.

Does that help?

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