Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TugboatEng on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
NX6
- Thread starter bfleck
- Start date
I agree. It is seldom advisable to make an immediate switch unless the enhancements are such to make it worthwhile. I will load it as soon as it is available to familiarize myself with it, but don't actually start production work with it until a couple of updates have occurred.
Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]
Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]
We're told sometime this month.
Immediately perhaps not but somebody has to at least try in order for the process of finding and fixing the early problems with any release. It is not usually the case that new releases are so totally useless as to cause major problems, but newer features are more likely to have their problems than those that bear little or no change from the previous release. With NX-5 the new hole feature may have had its teething problems but we simply avoided it until NX-5.0.3.2
I would load and test it on one machine without overwriting any existing data. If you can run it for a day or a week without things falling apart then you go live if not you just have to wait until a number of other people based on hearsay and NO testing provide a consensus that it is stable.
That said I generally wait for at least the first maintenance release before undertaking that process, unless a customer needs dictate otherwise.
Regards
Hudson
Immediately perhaps not but somebody has to at least try in order for the process of finding and fixing the early problems with any release. It is not usually the case that new releases are so totally useless as to cause major problems, but newer features are more likely to have their problems than those that bear little or no change from the previous release. With NX-5 the new hole feature may have had its teething problems but we simply avoided it until NX-5.0.3.2
I would load and test it on one machine without overwriting any existing data. If you can run it for a day or a week without things falling apart then you go live if not you just have to wait until a number of other people based on hearsay and NO testing provide a consensus that it is stable.
That said I generally wait for at least the first maintenance release before undertaking that process, unless a customer needs dictate otherwise.
Regards
Hudson
JohnRBaker
Mechanical
We're told sometime this month.
Sorry, but that is NOT true. There was a debate over on the Siemens PLM BBS over the meaning of the word 'launch' versus 'release'. A 'Launch' is a marketing event where you get a bunch of editors and analysts in a room and we show them NX 6 and they go away and write nice things about it.
A 'release' is when development turns the software over to Distribution and they upload it to the our Internet download site as well send the Master DVD to the company manufacturing the DVDs.
There was a press release that announced that the 'Launch' would occur in mid-May.
However, the 'Release' will not occur until mid-year, which is still at least 2 months away.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
Sorry, but that is NOT true. There was a debate over on the Siemens PLM BBS over the meaning of the word 'launch' versus 'release'. A 'Launch' is a marketing event where you get a bunch of editors and analysts in a room and we show them NX 6 and they go away and write nice things about it.
A 'release' is when development turns the software over to Distribution and they upload it to the our Internet download site as well send the Master DVD to the company manufacturing the DVDs.
There was a press release that announced that the 'Launch' would occur in mid-May.
However, the 'Release' will not occur until mid-year, which is still at least 2 months away.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
JohnRBaker
Mechanical
At the moment, the 'official' date for public consumption is 'mid-year'. Now if from this you've interpreted this to mean July, I would say that it at least proves that you can read a calendar ;-)
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
- Thread starter
- #8
John,
Thanks for update. I thought it was to be released in April and I was checking the downloads section nearly every day for last 2 weeks.
Do you know if the product will be more stable, that is fixing a lot of the memory leakage problems.
Thanks all for their comments
Thanks for update. I thought it was to be released in April and I was checking the downloads section nearly every day for last 2 weeks.
Do you know if the product will be more stable, that is fixing a lot of the memory leakage problems.
Thanks all for their comments
Look I'm no computer analyst but going by what I'm told or can read about Windows of any version you'll find asking about memory leakage in NX a bit like paddling in a barbed wire canoe and bailing it out during a tsunami; there's a limit to what you can expect to achieve. Windows memory management is a bit like military intelligence, both long considered by many to be a paradoxical terms.
So shoot me if I'm off with venting about this stuff. I can always try to plug the canoe with pages from the calendar.![[wink]](/data/assets/smilies/wink.gif "[wink] [wink]")
Feelin'![[deadhorse]](/data/assets/smilies/deadhorse.gif "[deadhorse] [deadhorse]")
Hudson
So shoot me if I'm off with venting about this stuff. I can always try to plug the canoe with pages from the calendar.
Feelin'
Hudson
- Thread starter
- #10
Hudson
Granted Windows has its problems, but I find it amazing that a major CAD program crashes so often especially when left open for a day. In fact the other day I lost a whole days analysis work because NX crashed the PC when I went to save the part. You know GTAC's solution to similar problems is to save regularly (which generally goes without saying though I had not in this instance, but it was all the other files that I had open that caused me the most discontent) and to reboot the PC every day. Why should the PC crash when the software crashes.
Granted Windows has its problems, but I find it amazing that a major CAD program crashes so often especially when left open for a day. In fact the other day I lost a whole days analysis work because NX crashed the PC when I went to save the part. You know GTAC's solution to similar problems is to save regularly (which generally goes without saying though I had not in this instance, but it was all the other files that I had open that caused me the most discontent) and to reboot the PC every day. Why should the PC crash when the software crashes.
Well you used to NEED to run the machine for longer than a day to perform some tasks. Thankfully these days that is quite seldom the case. I agree in that you do need to reboot at least daily, and it has been thus for different hardware and operating systems ever since I started doing this over 20 years ago. That includes Unix based systems, among others. The answer to what is causing this is easily blamed each upon the other depending upon whom you ask. You'll occasionally meet some super geek with a technically informed opinion, the only problem there is understanding it . My frustration that I vented about is informed by what I read and hear, but also my observation of using two or three major CAD packages under Windows all of which perform similarly well or poorly depending on you view as to whether having to reboot daily is such a bad thing.
Now if I can work my way back into the good books just enough to get some answers about the way NX actually performs; I struggle to understand why it takes so long to close files and how it is that when I close an assembly that it doesn't seem to really close all the files. See what I thought I meant when I did so was just shut it down NOW and give back that slab of memory so that I can continue working with this. This does seem to offer room for improvement, because I can often exit NX and restart a new session much faster than shutting down files and continuing to work in the current one, the inference being why not allow the same process to occur without shutting down the session.
Best Regards
Hudson
. My frustration that I vented about is informed by what I read and hear, but also my observation of using two or three major CAD packages under Windows all of which perform similarly well or poorly depending on you view as to whether having to reboot daily is such a bad thing.Now if I can work my way back into the good books just enough to get some answers about the way NX actually performs; I struggle to understand why it takes so long to close files and how it is that when I close an assembly that it doesn't seem to really close all the files. See what I thought I meant when I did so was just shut it down NOW and give back that slab of memory so that I can continue working with this. This does seem to offer room for improvement, because I can often exit NX and restart a new session much faster than shutting down files and continuing to work in the current one, the inference being why not allow the same process to occur without shutting down the session.
Best Regards
Hudson
JohnRBaker
Mechanical
While I don't doubt that something may have happened to your NX session and it crashed, but I don't think I've ever heard of a situation where NX caused the PC to crash. I suggest that if your PC crashed, that it was NOT NX that was the actual culprit.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
Same here... While I have experienced many frustrating crashes and lockups, the actual PC was still working and operational. This has been my experience for the last 20 years. Now, when operating something like Applicon on a main frame in the mid-eighties, it was not uncommon to bring the companie's entire system down on my own.![[bomb]](/data/assets/smilies/bomb.gif "[bomb] [bomb]")
Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]
Believe it if you need it or leave it if you dare. - [small]Robert Hunter[/small]
We had UGS (as was) in for a days consultancy as we were having sever memory problems on old unix system when working with large assemblies. We were closing assemblies and expecting to get our memory back, but we weren't the system was still holding on to the memory and in some cases, it was using more memory upon closing the part. Bsically we had to use book marks to ensure we only opened what we needed to save running into swap space towards the end of the day. Now we are running TCEng and NX4 we tell our users they MUST log out every day otherwise we will not support their helpdesk calls. Nowadays we advise people to rigorously manage their master assemblies, ensure the structure is up to date and we use open by proximity with true shape filtering to open only what we need too! We are currently trying to confgure the system to automatically run update stucture over night on each server to save someone a job.
Best regards
Simon
Best regards
Simon
I guess this topic has strayed a bit, but the posts are all collected here now so I want to pursue a couple of points.
John,
Never is an awfully big call and it would seem remiss not to mention something about that if only in passing. Even if we take it to apply only to NX excluding all earlier versions of UG. I'm quite certain that on occasion I have been working on a Windows PC using earlier versions of NX, and I have experienced the dreaded Blue Screen of Death. It was reasonably rare in the past and has thankfully not occurred any time that I can recently recall. By that observation for mine there has been a vast improvement and I would like to say for now on later NX that your claim appears to be borne out. I think by giving a qualified response I can do no better to congratulate you on the improvement.![[smile]](/data/assets/smilies/smile.gif "[smile] [smile]")
.
I don't represent myself as anything but a user in the sense that I can or would be qualified to attribute verifiable cause and effect when crashes occur. So speaking in the same vein the point made that originated this discourse was about something referred to as "memory leakage" by a poster who may or may not have applied the term any more strictly in the technical sense than I am able to. I look at the symptoms and if I'm unable to continue working because the system slows to a point of no return and/or the process says "not responding" then whether it eventually crashes or I kill the process the effects are that I lose my work and have to start again. Is that not a fair description? Can I therefore without stepping on any toes ask why?
For the sake of other readers, sometimes "not responding" (in the application status column of Windows Task manager) is a temporary thing and not to be concerned about. After a prolonged period of time you're simply apt to need to kill the process and start again, because it would take less time to cut your losses than to continue to wait for something that has quite obviously not turned out as you intended.
Simon makes the point about running Update Structure, and I agree it is a good idea and technically I would second the recommendation, noting also that he runs it overnight. Here I hazard a guess that is because it takes too long. In our case we are frequently working with vehicle assemblies for which we cannot get an update structure to finish. Ever.
At some point the inevitablity has to be recognized that the assembly gets too big. I want to perform this is order to be able to interrogate deeply nested branches of a very large product assembly, and I note that this assembly retains memory of the structure based on how it looked when it was last saved. Which is to also say that so do the sub assemblies retain memories of how they were saved. So given that if I set the preferred reference set to empty then I can open then close each separate child component (they're sub-assemblies) one at a time and succeed in manually updating the top assembly I'm perplexed that I can't get update structure to work. It seems that better strategies could be employed but that it probably just tries to open everything and is doomed in the attempt by the sheer size of the target.
The same might be said of my earlier question. I struggle to understand why it takes so long to close files and how it is that when I close an assembly that it doesn't seem to really close all the files. I can often exit NX and restart a new session much faster than shutting down files and continuing to work in the current one, the inference being why not allow the same process to occur without shutting down the session.
Lastly for the sake of other readers per my earlier posts. John and I probably agree that there are other kinds of crashes that sometimes occur for a few other reasons and that they're again probably irrelevant in terms of addressing topics pertaining to memory leakage. I have posted earlier that I have experience of what I put down to memory leakage using other major CAD systems under Windows. While I may have been somewhat sarcastic in doing so (sorry if y'all weren't amused), I mentioned it to mitigate the charge that NX could be blamed solely for the fact that you may do well to reboot on a daily basis.
Best Regards
Hudson
John,
Never is an awfully big call and it would seem remiss not to mention something about that if only in passing. Even if we take it to apply only to NX excluding all earlier versions of UG. I'm quite certain that on occasion I have been working on a Windows PC using earlier versions of NX, and I have experienced the dreaded Blue Screen of Death. It was reasonably rare in the past and has thankfully not occurred any time that I can recently recall. By that observation for mine there has been a vast improvement and I would like to say for now on later NX that your claim appears to be borne out. I think by giving a qualified response I can do no better to congratulate you on the improvement.
.I don't represent myself as anything but a user in the sense that I can or would be qualified to attribute verifiable cause and effect when crashes occur. So speaking in the same vein the point made that originated this discourse was about something referred to as "memory leakage" by a poster who may or may not have applied the term any more strictly in the technical sense than I am able to. I look at the symptoms and if I'm unable to continue working because the system slows to a point of no return and/or the process says "not responding" then whether it eventually crashes or I kill the process the effects are that I lose my work and have to start again. Is that not a fair description? Can I therefore without stepping on any toes ask why?
For the sake of other readers, sometimes "not responding" (in the application status column of Windows Task manager) is a temporary thing and not to be concerned about. After a prolonged period of time you're simply apt to need to kill the process and start again, because it would take less time to cut your losses than to continue to wait for something that has quite obviously not turned out as you intended.
Simon makes the point about running Update Structure, and I agree it is a good idea and technically I would second the recommendation, noting also that he runs it overnight. Here I hazard a guess that is because it takes too long. In our case we are frequently working with vehicle assemblies for which we cannot get an update structure to finish. Ever.
At some point the inevitablity has to be recognized that the assembly gets too big. I want to perform this is order to be able to interrogate deeply nested branches of a very large product assembly, and I note that this assembly retains memory of the structure based on how it looked when it was last saved. Which is to also say that so do the sub assemblies retain memories of how they were saved. So given that if I set the preferred reference set to empty then I can open then close each separate child component (they're sub-assemblies) one at a time and succeed in manually updating the top assembly I'm perplexed that I can't get update structure to work. It seems that better strategies could be employed but that it probably just tries to open everything and is doomed in the attempt by the sheer size of the target.
The same might be said of my earlier question. I struggle to understand why it takes so long to close files and how it is that when I close an assembly that it doesn't seem to really close all the files. I can often exit NX and restart a new session much faster than shutting down files and continuing to work in the current one, the inference being why not allow the same process to occur without shutting down the session.
Lastly for the sake of other readers per my earlier posts. John and I probably agree that there are other kinds of crashes that sometimes occur for a few other reasons and that they're again probably irrelevant in terms of addressing topics pertaining to memory leakage. I have posted earlier that I have experience of what I put down to memory leakage using other major CAD systems under Windows. While I may have been somewhat sarcastic in doing so (sorry if y'all weren't amused), I mentioned it to mitigate the charge that NX could be blamed solely for the fact that you may do well to reboot on a daily basis.
Best Regards
Hudson
- Status
Similar threads
- Locked
- Question
