Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations SSS148 on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Switch to NX 9.0 slows down custom codes 1

Status
Not open for further replies.

Twullf

Mechanical
Jan 24, 2012
196
I have a program that I wrote in NX 7.5, where it works very quickly. This is designed to run in an assembly. In a nut shell the program does the following:

User selects face to be checked
User selects face being checked against
user selects center line (usually a spline curving in one direction)

Program places the datum on the spline
Program creates Wave-linked faces for the faces selected
Program places an intersection curve on both faces
Program takes 3 measurements
Program writes data into a file
Program moves the datum (which moves the intersection curves)

Repeat data gathering and move till the first surface selected runs out.

In NX 7.5 this runs nice a fast, but in NX 9.0 (using models created in NX 7.5 since I'm still setting everything up and making sure it works) the program runs incredibly slow. As in walk away and come back in half an hour and hope it is done.

Does anyone know if there have been significant changes in how intersection curves are handled in NX 9, or if it might be the wave linked faces, or if it has to do with something in the assembly functions. The program also frequently uses an update model callout to make sure the changes have been accepted in the 3D environment.

Thanks for the help.
 
Replies continue below

Recommended for you

Have you relinked the program with NX9 dll's?


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli
 
I did not use any dll's, the program was written in VB from scratch. Much of the UG commands I got by recording journals and looking at the code resulting from it.

So no, but the other programs I wrote have worked without a problem.
 
Have you re-saved (or refiled) the parts in NX 9.0 and then reopened them and tried it again?

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
That seems to have done it. It did not occur to me that the files need to be saved as NX 9.0 files.

Thanks John!

Since I have your attention. Another program creates a line as part of a much longer process, its length is set by an expression. NX 7.5 will create a line of 0 length if the expression is zero, NX 9 will not create the line.

NX 7.0 worked the way NX 9 currently does, but I prefer how 7.5 did it. Is this a mistake that was fixed from 7.5 to the next, or a feature that will be added back in?

Thanks again.
 
Could you provide an example of this, preferably something that can be opened in BOTH NX 7.5 and NX 9.0 so that I cen test it to make sure that it's truly a regression or not?

As for the other issue with the re-save/refile, many people are not aware of the fact that when a legacy UG/NX file is opened in a newer version of NX (not generally MR's but from one full release to a newer one) that the part files have to go through a 'schema' update and while most of that work is done upon opening one of these files in the newer version of NX, the data is still only in a sort of temporary format which means that accessing it may not be as efficient as it would be if NX had not needed to perform this schema update before NX could open it or access any of the data. Of course, if you run 'refile' or open and subsequently save the part and then reopen it again, none of that extra baggage is needed and therefore the data records are as clean as they can be and when accessed, it will be done as efficiently as possible.

Note that before anyone asks, while it is highly recommended that you run 'refile' whenever a new version of NX is installed and put into production, and this includes, when practical, all of your standard parts such as Family Table Parts and the Reuse Libraries (not so much the master templates although that's advisable as well, just not as critical as the actual family members), the ability to update parts on-the-fly is and will remain fully supported, just that you will be paying for a bit of additional overhead, as you've discovered, if the parts are not actually saved after having been opened and updated. And for the record, we can currently open, without needing to use 'refile', parts from as far back as UG V9.1. In fact, I carry with me a part file that has not been saved in 21 years and it opens just fine in NX 9.0.1.3. Granted, it's not all that complicated of a model, a 3D wireframe piece part, with a few simple dumb solid bodies in it, as well as a fully annotated 'J-Size' Drawing. And if you edit any aspect of the model, the Drawing, and all of it's views, dimensions, notes, etc, they update just fine.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
Here is the subroutine I am using to create the line.

The program normally creates a point on a spline, at a distance specified by an expression, and a datum is placed on the spline, normal to the spline, then the line is placed starting point on the initial point, within the datum, set in the x direction.

The subroutine is only the line part of the process. The program is really long and convoluted so I think the sub is sufficient. Let me know if it is not and I"ll try to throw something together.
 
 http://files.engineering.com/getfile.aspx?folder=9dbeb086-6588-4620-8d07-8012d67848fd&file=PlaceOffset.txt
I'm sorry, I don't 'program' (except for the occasional GRIP program or two). I was honestly expecting a part file where NX was throwing an error when, after an edit of some kind, a line object was reduced to a length of zero .

You may have to bring this to GTAC's attention.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
I have verified, at least to myself that this functionality has been lost.

In UG 7.5

create an expression in mm for the length of a line.
Create a line in 3D space, set the direction as an axial direction and set the length of the line as the expression.
If the expression is changed to read 0 the line becomes a line of zero length which is still a "good" feature.

In UG 9.0

follow the same steps, create an expression
create a ilne using the expression to define the length
if the expression is changed to read 0 the line option fails.

In the provided UG file, attempt to change the expression to 0. This file will work in both UG 7.5 and 9.0.
 
 http://files.engineering.com/getfile.aspx?folder=5e1079e1-0ac7-4cbb-a564-6909daa05453&file=LineExample.prt
OK, I see what you mean and I suspect that someone felt that this was an undesirable situation and has subsequently decides to not support this behavior (some other customer probably contacted GTAC and opened a PR complaining about this).

Now I'm willing to open a PR asking development to return the behavior back to that it was in NX 7.5 since in your situation it would appear that your program needs to reduce the length of the line to zero. That being said, I further assume that from your point of view, this would be the same as if the line did not exist, correct? If this is the case, may I suggest that perhaps it would better to simply 'suppress' the line feature if it's value is reduced to zero.

To show how that can be done, look at the updated version of your part that I've attached to this post. I've added a couple of additional expressions, one controlling the length of the line and second expression which will suppress the 'Line' if it's length is reduced to zero. Therefore, as far as NX 9.0 is concerned, the line does not exist when it's length was reduced to zero so there's NO error. Note that the part file will work in both NX 7.5 and NX 9.0.

Anyway, take a look and see if this approach can be used to give you the behavior that you're looking for.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
 http://files.engineering.com/getfile.aspx?folder=5231f5e9-2824-48a7-b2ed-3844c798f3b4&file=LineExample-JRB-1.prt
As one who prefers clean files, and not being able to open your sample file, I can see why a zero length line would fail. That said, I would think that if a line length was driven to zero, then it should be deleted as non-existent. However, I can also see cases where some lines may go to zero in a certain situation, but have a length in others. In this case tyhe suppressed line would be the best solution for handling a zero length line.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli
 
the line in my program is being used as an offset which is being referred to by a sketch. The line places the sketch in 3D space. It is external to the sketch because when I wrote the program you could reduce the line to 0 in 3d space but not in the sketch environment. The length of the line will vary depending on which sketch is being placed, which is controlled by the expressions. After the program has run and the user is completing the model a smoothing operation is needed which will sometimes take an offset that is zero to a non zero value, or change a non-zero value to 0 depending on what is needed in each situation.

So unfortunately I can not suppress the feature because everything after it would be suppressed including the sketches I NEED. Also if the operations are accomplished without the offset the user will be unable to change the value later without having to go into the tree and put in additional work to add the offset.

Unfortunately when the line "fails" in NX 9.0 my sketches have nothing to refer to, and will either fail as well, or they will stay in the previous position, which will not aid in smoothing operations.
 
Can you change your model using something like an offset datum plane to position your sketch since you can reduce a datum offset distance to zero with no problems?

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
its positioning within the datum off a the point on a spline. The datum is normal to the spline. If the feature is suppressed it can't be referenced by future features and the sketch uses it to know where the (for lack of a better term) the zero point is for each sketch.

This "zero point" is the base point for how it is positioned, but if the "zero point" is moved, either by changing the length of the line or shifting the station, the entire sketch moves as well.

Datum controls z position and orientation, line controls x direction, and y is controlled inside the sketch off of the end point of the line. Thus fully positioning each sketch.

A normal part has around 27 such sketches.

As mentioned before the length of the line will be modified later to smooth the surface created by the sketches.
 
Since you're got the program as an example, I recommend that you contact GTAC and have them open the PR. I would argue that this is a regression since it no longer allows you to do what you were able to do in NX 7.5.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.
 
Devil's advocate - The code did not work in NX7.0, does in NX7.5 and does not in NX9.0. "NX 7.0 worked the way NX 9 currently does, but I prefer how 7.5 did it."

Is this really a regression or is 7.5 the mistake that was reverted/fixed back to the 7.0 functionality at some point between 8.0 and 9.0. Has the code been tested at 8.0 and 8.5 to see where the actual change took place? Some programmer must have had a reason to fiddle with the code at 7.5 and then again later.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli
 
PR 7109581 Opened on the subject.

Thanks for the time of everyone who commented.
 
Just a small workaround idea.
How about having an intermediate expression that controls the line length that has an IF expression such that it uses the value of the original expression if its >0 or some suitably tiny value if the original expression =0?
Something like:
[tt]if(length>0)(length)else(0.00001)[/tt]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor