NX4 Save As NX2 1

[PieBoy]

Hello all, probably a simple answer, tried to search but it's not working.

We have a guy doing some design work, he is working on NX4, our customer requires NX2 files. Can someone guide me thro' the method of "save as" or exporting to NX2.

Thanks in advance for your help.

 

[looslib]

By most accounts, Pro/E V17-V19, where not really new versions, just cosmetic interface changes and bug fixes. Therefore they had the same underlying kernel and indeed did support backward compatability. BUT, that was years ago.
Wildfire 3 does have a method for allowing WF2 to open its files. However, you do not have a parametric feature tree to allow editing of the existing WF3 features. You can add new features, which WF3 will recognize, but prior WF3 features are now not parametrically editable.

As to the biggest reason that these file types are not backward compatable is what John has explained. CAD files are not stored as simple text entries, but as mini dataabses of information with their own structures. How does an older version know what to do with a new feature type that did not exist when it was released?



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

Ben Loosli
Sr IS Technologist
L-3 Communications

 

[cbrn]

Hi,
first of all, a correction to my previous: Ansys continues calling UG in background for the parametrical update, so it's really not a good example...
As for the description of a topology, I can understand what you Looslib and John are saying. What I meant is another thing: of course, if you re-format the database, the old version won't know where and how to look for what it needs; but let's say the database structure is left the same: in this case, the problem arises when there are NEW database entries (the new features). I 100% agree with that. But at this point, the "read-in" routine could skip the unknown entries and simply give you the B-Rep of the final resulting solid. In fact, if the pure B-Rep of the solid was stored within the database, it would always be possible to at least "re-build" the resulting solid, and you could get something like a tree where some features appear together with some "unparametrized" ones. Probably I'm not saying that with the proper terms, I only know that a "mixed-mode" 3D reader like that has been experimented with success as a thesis work at the Univ of Padova (never published, afaik) for an existing CAD kernel (maybe ACIS, but I'm not sure). However, provided that some general info is stored in the database, the reconstruction of a mathematically-defined b-rep solid is always possible. The question is if users would stand handling bigger files and if programmers would stand having to write more complex routines...

Regards

 

[looslib]

UGS has done this by providing the Parasolid export file, which can be opened in an older version of UG/NX.

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

Ben Loosli
Sr IS Technologist
L-3 Communications

 

[hudson888]

If your supplier has an NX-4 licence then that can be used to operate older versions of UG. So you should ask him to create all his designs in NX-2. For what he has done thus far he can probably move the models back without losing too much, but he'll have to re-do the drafting.

Since nobody has mentioned this earlier I thought you might like to know.

 

[ewh]

He won't lose anything but the parameters...

 

[moovrr]

I may be singing from a different sheet here, but surely if you were a programmer writing an export routine for UG, then you would take the existing functionality/features in NX4 for example and knowing what is possible to translate directly to NX2 write the export routine to convert the like for like features, and where there is no NX2 function/feature which compares with NX4 convert this to a dumb unparameterised feature.

This approach means that NX2 would read a NX4 prt file which is configured correctly because NX4 knew what NX2 could cope with, and formatted the model appropriately.

All of the previous chat is based around NX2 receiving an unknown feature, which obviously it couldn't cope with.

 

[JohnRBaker]

A good idea in theory, but it's not practical as the cost to maintain the code would eventually become prohibative.

To show you what I mean, let's just pretend that the world began with NX 1 (it actually goes back to V11.0).

OK, when we finished with NX 1, there was no work to do since there was no 'old' versions to go back to.

Now we finish up with NX 2 and we have to create a converter to go back to NX 1. Extra work, but probably not a big problem.

However, after finishing up NX 3, we have to create the converter to go back to NX 2 AND update the code for NX 1.

And after NX 4, we have to develope the new code to go back to NX 3, as well as update BOTH the NX 1 and NX 2 versions of teh code.

And finally after NX 5, we have to develope the new code to go back to NX 4 and update the other 3 versions, for NX 1, NX 2 and NX 3.

And know that there's going to be an NX 6 and hopefully an NX 7 and 8 and 9 and ...

Notice a trend here? Now think what this would be like if after we had finished NX 5, we would have had to go back and account for all 13 legacy versions of UG/NX.

Image what the level of effort could grow to when you consdier that at each new release, dozens of new feature types created or major changes to existing ones, that would have to be mapped back to the hundreds of object types already in the legacy versions of UG/NX.

To show you what I mean, the following are new Features or significant changes to existing Features that were added in NX 5 and which would have to be accounted for when moving back to a legacy version.

Point between points.
Blend end caps.
Face Blend across non-tangent faces.
Instance Geometry.
Features across mulitple bodies.
Multiple draft angles in Extrude.
Trimmed Sheet.
Law Extension.
Sketch Offset Curves.
Circuler Blend Curves.
Thicken.
Untrim.
Unsew.
Offset Emboss.
Assembly Constraints.
JT Facets.

And this doesn't include any changes to expressions, attributes, drafting, etc.

Anyway, I hope you can start to understand why this would be virtual impossible task to accomplish, release after release after release, with any hope of maintaining any kind of long term reliable code that would continue to output robust data based on a growing list of legacy versions, each with their special issues, constraints and limitations when compared to the changes in the latest versions of NX.


John R. Baker, P.E.
Product 'Evangelist'
UGS NX Product Line
SIEMENS
UGS PLM Software
Cypress, CA

http://www.siemens.com/ugs

http://www.plmworld.org/museum/

 

[cbrn]

Hi,
"infinite" backward-compatibility would of course result in impossible work.
But, always in theory, a CAD company could support compatibility for 2 past releases, not more, thinking that a user / company can "miss" one release but it's unlikely they will miss two releases (or they have definitively run out of support/maintenance as they have chosen to stay "frozen" on a release... Absurd, but who knows...).
Come on, what Moovrr is saying is the same that I was writing previously, and has already been done somewhere by somebody.
I believe the real fact is that CAD companies DON'T WANT to do this, because any kind of interoperability is often a threat...
Maybe cynical?

Regards

 

[JohnRBaker]

At least we have infinite 'forward' compatibility, which puts us way ahead of most everyone else out there. I have a Unigraphics V9.1 file that has not been saved (refiled) in over 14 years and I can open it straight-up (using File -> Open) in the latest maintenance release of UGS NX 5 with not issues what-so-ever, and this file contains solid as well as wireframe information and includes a fully annotated 'J' size drawing.

And one last thing, based on my working with customers for 27 years (and being one myself for 3 years), it would be naive for us to think that we could arbitrarily limit any sort of 'backward' compaibility scheme to only "2 past releases, not more". Note that the current Parasolid-based backward exporting tool supports moving surface and solid data back to Unigraphics V11.0. Granted, I'm sure that we don't get a lot of people needing the 'Wayback Machine' to send data that far into the past, but our current mechanism is such that we get what level of support that we do have for little or no incremental effort since it's based on code already built into the Parasolid toolkit.

Anyway, this has been an interesting discussion and one that we have had oursleves internally on more than one occasion, but it's still basically 'pie-in-the-sky' in terms of something like this ever being truly practical.


John R. Baker, P.E.
Product 'Evangelist'
UGS NX Product Line
SIEMENS
UGS PLM Software
Cypress, CA

http://www.siemens.com/ugs

http://www.plmworld.org/museum/

 

[moovrr]

I'd like to come back to you JohnRBaker on a couple of points just to show that there are some strong customer opinions about backward compatability;

As per 'cbrn's note, we 'the customer' would not expect infinite backward compatability, since this is not good business sense for us to deal with suppliers who insist on using a software version say more than 5 years older than the current release. This would bring about concerns over their software support from the vendor and inturn their ability to support their customers, in short 'a risk'.

Secondly, this has been done by a 'small' UK company called Delcam, of which there is a Delcam USA. They continue to support previous versions of their software Powershape with backward export-ability, albeit on a smaller set of features/functions than UG but with a smaller development team, time frame and budget.

One final question, which I'm sure will not convince you that 'the customer is always right'; at what point will previous versions of NX not support the translated data from the current version due to IGES or Parasolid versions being updated?

 

[JohnRBaker]

I'm sorry, but even if the "customer is always right", wishing it does NOT make it so.

And despite your claim that some small CAM company supports some level of backward compatibility "with a smaller development team, time frame and budget" this does not diminish the fact that this would be virtually impossible with a complex MODELING package like UGS NX that is continually being enhanced and new capabilities being added to it.

And even if from where you sit, compatibility back 2 or 3 releases sounds like a reasonable level of support, experience has taught us that we cannot expect all of our customers to be so magnanimous, not when they've gotten a taste of something that they will continue to expect more and more from. There are times when it's better to just hunker-down and stick to your guns than to start down a path that could commit you to untold costs and which will always be subject to serious issues of being able to maintain the needed quality was as well as being able to meet continuously changing customer expectations.

As for our current Parasolid-based scheme of backward compatibility and our ability to continue to support that, with UGS NX 5 I can export a topologically valid and accurate representation of any Solid and/or Surface model back to Unigraphics V11.0, which was released to our customers in January, 1996 (and every version in between), making for a move of better than 11 years into the past, as it were. Furthermore we see no technological constraints that will prevent us from continuing to provide that level of support into the foreseeable future.


John R. Baker, P.E.
Product 'Evangelist'
UGS NX Product Line
SIEMENS
UGS PLM Software
Cypress, CA

http://www.siemens.com/ugs

http://www.plmworld.org/museum/

 

[cbrn]

Hi,
OK, as "announced" by John R. Baker a pair of replies before, we'd better stop it now.
As far as I understand, and the more I read the replies the more I get convinced of it, the "non-backward" compatibility is purely a matter of politics and not technics.
Nobody here has said that he expects any CAD package to be able to save backward to the original first version. Nobody here is so deficient to claim to use a 25-years old CAD and interoperate with 2010 CAD users. Come on, we are not so stupid, I repeat: we all agree that, whenever for some strange reason this may be the case, "dumb"-aparametric representations of geometry, such as IGES, STEP, Parasolid etc, are far sufficient because what you need (???) is to open "something" that still makes sense.

When we "want" limited backward-interoperability with almost-full features, it's in order to simplify the interchanges with the Supplier chain, or even inside the same company (do you mind how many UG seats there are in Voith-Siemens Hydro? Or in Andritz - VaTech Hydro? Do you think that all the subsidiaries make the software updates in one morning altogether??? The curious thing is that most of the UG users who mostly need internal backward-compatibility are those very big companies which began their CAD history right with UG...). Suppliers are tired to be "obliged" to follow the upgrades of their bigger contractors, contractors are tired to be "obliged" to synchronize with all the suppliers, and so on...
At my company, which is a subsidiary of a multinational Group, we are currently obliged to run two releases of NX simultaneously, which is a VERY dangerous situation, I can assure you!!!!
But of course, it's been decided that this kind of needs are irrelevant, and so they will be. No hope, good luck to everybody.

Regards

 

[JohnRBaker]

As far as I understand, and the more I read the replies the more I get convinced of it, the "non-backward" compatibility is purely a matter of politics and not technics.

You could NOT be more wrong. When a technical problem is so large and complex that it would drain an unacceptable amount of resources away from other more critical areas of R&D, while at the same time delivering less than fully desireable results to a limited segment of our customer base, well if you wish to see that as a 'politcal' call, so be it.

As for your suggestion that since you would NEVER expect to go back "to the original first version" that this may somehow reduces this to a trivial undertaking is naive at best. To go back even ONE version with any degree of reliablity and level of coverage and thus usablity, would account for perhaps 60% - 80% of the cost of going back 5 or 6 versions, so that would not automtically remove the finanical barriers.

As for your willingness to accept "limited backward-interoperability with almost-full features", the problem is that these files would then be reinserted back into your, and your suppliers/customers, workflows as if they were fully-fledged models with the engineers original design intent still intact, only there would be gaps, gaps that users would have no direct control over, gaps which someone will expect to be filled, either by going back to the vendor (i.e., UGS) and demanding that they do a better job, or that they expect their own organization to 'bring BACK up to snuff'.

And here in lies the long-term problem when one is willing to accept less than what they really need yet are given the impression that they can get it for free. Your workflows will be compromised by the hope of NOT having to keep up with the latest and greatest, by having a way of 'having your cake and eating it too'. You'll not install that latest release, the one with the bug fixes, but will instead demand and expect that the older releases continue to be supported for longer periods since you now can move data back and forth while losing only a bit of your model's original content, losses that you're willing to accept, until of course something critical gets lost and then what? Blame it on the code that was not able to preserve data which was critical to YOUR processes, something the vendor should have taken into account?

I'm sorry, but the consequences of something like this, both in terms of the impression that 2nd and 3rd parties would get from having to deal with files obviously comnpromised and therefore perhaps the fault of the software leading to the conclusion that the vendor (i.e., UGS) was not able to deliver products 'suitable for the intended use', or for our customers who made an investment in technology based on getting a certain level of capabilities and functionality and then as a result of using it as it was designed, they may find that they have lost critical content and created data that will forever be a problem going forward because it was compromised at some point in the past, all for the sake of wishing to avoid some administrative hassles or inconvenient scheduling.

BTW, we're open to others viewpoints here as it would be interesting to see if there is a consensus that despite the potential issues that I've rasied, do you think that you would be able to gain enough extra value so that you would want us to invest in this capability.



John R. Baker, P.E.
Product 'Evangelist'
UGS NX Product Line
SIEMENS
UGS PLM Software
Cypress, CA

http://www.siemens.com/ugs

http://www.plmworld.org/museum/

 

[hudson888]

John,

Without making it a rod for everyone's back would it be possible in the future that if you're running NX-6 then you can see, open, print the drawing and maybe add an NX-7 file to your assembly. I think that would be some sort of added functionality that people could use so that they're not dead in the water unless everyone upgrades at the same time.

If you can inter operate between UG and I-deas, then it seems logical that you might be able to do something similar between later versions of UG.

In terms of going back to NX-6 from NX-7 if it is worth having functionality that transfers it back with acknowledged risk and/or cutting your losses in doing so then all so good. As many users would know, we use the same techniques from one version to the next. Also in the early stages of taking up an upgrade somebody saves an old model in the new version and bingo it is invisible to anyone who hasn't loaded the latest UG.

On the other hand once a file is saved in NX-7 I would not expect to be able to edit it using earlier versions on an ad-hoc basis. Sounds to me like that would be asking for trouble. Too much to go wrong.

BTW for EWH. I suggested earlier that the originator may care to do something that loses them the parameters. You know UG is a really powerful system and you can find ways to do 99% of what you want even without parameters. On the other hand a lot of design changes happen at a level that involves most of the model so that many designers prefer to start over as opposed to analyzing another user's technique. In my experience I wouldn't sweat it so hand.

Regards

Hudson

 

[cowski]

many designers prefer to start over as opposed to analyzing another user's technique

Wow, what a waste of time. That might be justifiable for parts with low feature counts, but on the other hand those would be the easiest to figure out and modify. On large parts that is just a waste of your time and a waste of the software's key strength. Sounds like some training and/or a few standardized modeling techniques could do your organization a world of good.

 

[ewh]

Who's sweating it? I made the comment to point out that backwards compatability isn't always worth the effort (cost) involved, as John has pointed out. Why have a supplier make the effort of remodeling and redrawing from NX4 to NX2 when a parasolid will meet your requirements? Do you actually require "live" drawings from your suppliers? As a "supplier", we don't give our customers the actual files, but parasolids and cgms.
An unparameterized body is still very useful, and can originate in other CAD systems. The new Edit Face commands are a very powerful tool in using these type of bodies.

 

[hudson888]

Interesting perspective! I tend to think that on small parts I'll work through the other guy's technique because the data isn't all that deep to begin with. And yet if the number of steps are few I have less to lose if I have to start again because the data is devalued by a translator for example.

On the other hand I do a lot of work on very large parts with heaps of parameters and mostly based on surfaces that come out of other industrial design packages. In a perfect world everyone would model the same way, but as complexity increases different individuals solve the more difficult problems in different ways. That is what usually leads to models that become do complex and they are often easier to rebuild than maintain. I even advocate modeling onto the end of things that would otherwise require rolling back too many features to tackle. If it works just as well why not trim off and/or simplify away an unwanted appendage that can't otherwise be deleted because something happens to depend upon it. I know how to use direct modeling and I use it. Replace face is a fantastic tool with many appropriate uses.

I see many users who have a fixation with purist parametric modeling technique. I don't mind engaging and refuting this attitude of mind. In the real world time is money, sometimes you just have to bite the bullet and edit the parameters even if it is hard work, many times I'll find you a short cut.

When it comes to your comment about training. Maybe you're right, and I'd love to re-train everyone in the organization to have the same experience and work ethic as I do. Unfortunately I deal with really large organizations with lots of legacy data and users who make bad models that we can't always afford to fix. That's why I love using techniques in UG that are powerful enough to allow me to succeed with poor quality models quickly and easily.

If on the other hand you're trying to suggest as I suspect that I need re-training. We all don't really know one another on this forum, (except for John, who everyone probably knows), so don't show your prejudice by insulting those who may know better than you and write here to help share that with others. I'd suggest rather than a few standardized modeling techniques you learn to use all the tools that UG gives you to your greater benefit.

Regards

Hudson

 

[JohnRBaker]

A comment about working in an assembly with 'incompatible' (for whatever reason) or foreign data. You can bring faceted models into an assembly from most any source and if nothing else, use it as a placeholder until you get the 'real' data. You can assign attributes to these faceted components and they can be referenced by a Parts List as well as used when performing interference checking, clearance analysis, extraction path planning, etc.


John R. Baker, P.E.
Product 'Evangelist'
UGS NX Product Line
SIEMENS
UGS PLM Software
Cypress, CA

http://www.siemens.com/ugs

http://www.plmworld.org/museum/

 

[cowski]

Hudson,
I apologize if you found my post offensive. It was not intended to be an insult, and indeed was not even directed at you but rather the 'just start over' mentality of the 'many designers' that you indicate. Now that I reread my post I can see that I should have explained that better.

As a UG user, if I consistently ran into 'large' models that were so bad I had to redo them (whether from internal or external sources), I would take a look at what could be done to improve the current workflow (which might include some training or standardization). I agree that UG has many useful tools that can be used in many strange and wonderful ways. I'm always looking to expand my knowledge and skills and you will be glad to know that I am not a 'parametric purist'.

Welcome to the forum, if you stick around a while you will get to know the regular posters better than you think (eg you already know that I have a prejudice toward using existing work rather than starting over). I look forward to learning some tips and tricks from you and I hope that I have a few that you will find useful.

 

[ewh]

Hudson,
As cowski infers, sometimes we shoot off the cuff, but we do all have in common the desire to use this tool more effectively. Some of us are more biased than others, but typically, if you can explain a better way to accomplish something, we're all ears (eyes). Along with the UGS BBS, this is the most valuable forum I have found on the web for sharing this type of knowledge.
We have had the very good fortune of having John Baker join in with us, and if you haven't personally seen him in action, you are missing some of the magic that can be accomplished with the software. I strongly urge you to attend a user group function when John is presenting. You won't regret it.
Welcome to the group!