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!
items Siemens needs to fix
- Thread starter uwam2ie
- Start date
JohnRBaker
Mechanical
Well, is it fixed in NX 6 or NX 7? If it's fixed in NX 6, you'll be able to get it in about 2 1/2 weeks.
However, let's get back to your issue with I guess you meant trimming curves in the sketcher and losing constraints. Can you provide an example? Perhaps there is a workaround that could be used until you're able to get a real fix.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
However, let's get back to your issue with I guess you meant trimming curves in the sketcher and losing constraints. Can you provide an example? Perhaps there is a workaround that could be used until you're able to get a real fix.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
- Thread starter
- #3
- Thread starter
- #4
JohnRBaker
Mechanical
Here's an image of the results I got following your examples and instructions. Note that I'm running NX 5.0.5.2 (granted, NX 5.0.5.x won't be available until the end of July). Not sure what it was that you expected to see since what I got was exactly what I was expecting.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
- Thread starter
- #6
JohnRBaker
Mechanical
That file format is unknown to me or my system. Send a .zip file instead.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
- Thread starter
- #8
... it works with 7zip to find :
the avi is about 45mb zipped its 6mb
Eng-tips file upload failed with the zipped archive
the avi is about 45mb zipped its 6mb
Eng-tips file upload failed with the zipped archive
JohnRBaker
Mechanical
I don't see what the problem is. The results, in terms of the number and types of constraints, are exactly the same irrespective of the order in which you perform the trim operations. Granted, the symbols may end up being displayed in different locations, but the results are identical. If you think that this is a problem, please explain how the problem manifests itself to you and what is it that you can NOT do as a result of this behavior?
BTW, having what appeared to be previous results, in this case geometric constraints, change after an edit in some other part of the problem (sketch) is the typical behavior for any system based on the solving a simultaneous equations, which is how our Sketch constraint solver works. Every time a constraint is added, deleted or edited, the complete set of equations controlling the sketch is solved, and even if logic might say that there was NO need to change or move a constraint(s), that is not an unexpected occurrence when dealing with systems like this. It's the last and final result that counts. What it looked like at some intermediate point in time is not relevant since Sketches, unlike feature models, are NOT solved in a timestamp order that can be rolled-back or forward at any time with the assurance that the results will not change. This is just the way it works.
And before you ask, since our 2D and 3D solvers, based on what's known as the DCM tool kits, are the most widely used constraint solvers in the CAD industry, licensed from us by virtually all of our competitors, that behavior that you're seeing in NX 5 is what you would see most anywhere else.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
BTW, having what appeared to be previous results, in this case geometric constraints, change after an edit in some other part of the problem (sketch) is the typical behavior for any system based on the solving a simultaneous equations, which is how our Sketch constraint solver works. Every time a constraint is added, deleted or edited, the complete set of equations controlling the sketch is solved, and even if logic might say that there was NO need to change or move a constraint(s), that is not an unexpected occurrence when dealing with systems like this. It's the last and final result that counts. What it looked like at some intermediate point in time is not relevant since Sketches, unlike feature models, are NOT solved in a timestamp order that can be rolled-back or forward at any time with the assurance that the results will not change. This is just the way it works.
And before you ask, since our 2D and 3D solvers, based on what's known as the DCM tool kits, are the most widely used constraint solvers in the CAD industry, licensed from us by virtually all of our competitors, that behavior that you're seeing in NX 5 is what you would see most anywhere else.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
- Thread starter
- #10
- thank you John on reply
but I can not accept
"typical behavior"
we have done the same in NX2 and it works fine.
In NX5 other combination tangency constraints were auto. removed works fine in NX2. NX5 enhancement or magic or ... ?
thx in ad
Master or Slave?
but I can not accept
"typical behavior"
we have done the same in NX2 and it works fine.
In NX5 other combination tangency constraints were auto. removed works fine in NX2. NX5 enhancement or magic or ... ?
thx in ad
Master or Slave?
JohnRBaker
Mechanical
But please explain the symptoms, NOT what you see as a 'problem', but the SYMPTOMS, meaning something that this prevents you from doing that you wish you could do. If all that you can report is an 'odd behavior', but which there is no negative impact on your ability to accomplish your tasks, exactly what is it then that you want us to spend our time and resources on 'fixing' and to what end or benefit will this expenditure result? In other words, if nothing is broken (in terms of the software not being able to do what you need it to do), what do you want us to 'fix'?
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
- Thread starter
- #12
JohnRBaker
Mechanical
You have yet to offer a single concrete example of something that does NOT allow you to continue to work other then your apparent paranoia over the idea that perhaps the manner in which constraints are being applied is NOT to YOUR liking.
Answer this question honestly now:
If you had created your example sketch with the 'Show All Constraints' option toggled OFF, when and what is it exactly that you would have noticed that would have prevented you from continuing to work on your model?
Please be specific.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
Answer this question honestly now:
If you had created your example sketch with the 'Show All Constraints' option toggled OFF, when and what is it exactly that you would have noticed that would have prevented you from continuing to work on your model?
Please be specific.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
John,
I tried to see what this was all about and found that WINRAR will help with opening the archive with the AVI file inside it.
I think what I'm seeing in NX-3 is that if you quick trim the segments out of the circle crossing the square then you can make selections in a random order or even simply go around in a circle picking line, arc, line, arc, and it gives you a predictable result. In NX-3 all the coincident corners were left with point on curve constraints also.
In later versions and we'll stick with NX-5 for now you really benefit if you select all the arcs first and all the lines second. In most cases you'll be left with just a coincident constraint on the resulting corners. Depending on the order that you apply the trims you may get an occasional point on curve cross on top of the coincident constraint and these really don't matter. I did find following the example as given that one corner would have a point on curve only and then you needed either to add the coincident constraint of later apply a trim to properly constrain the sketch. You would probably only find out when you start to add dimensions or manipulate the sketch but you can trim or extend to correct the errant corner very easily.
Now perhaps it would be better if it was that little bit more robust. But then again I don't come across these problems that often so perhaps its not that big a thing.
Perhaps this thread ought be entitled things PLMS could fix. The idea that it "NEEDS" to be done implies that it can't be used or isn't fit for its purpose. Some things like the new hole feature in NX-5 had a few teething problems that needed fixing and were quickly responded to. Other things like this example could be easier to use but if used correctly shouldn't be that hard to live with.
Cheers
Hudson
I tried to see what this was all about and found that WINRAR will help with opening the archive with the AVI file inside it.
I think what I'm seeing in NX-3 is that if you quick trim the segments out of the circle crossing the square then you can make selections in a random order or even simply go around in a circle picking line, arc, line, arc, and it gives you a predictable result. In NX-3 all the coincident corners were left with point on curve constraints also.
In later versions and we'll stick with NX-5 for now you really benefit if you select all the arcs first and all the lines second. In most cases you'll be left with just a coincident constraint on the resulting corners. Depending on the order that you apply the trims you may get an occasional point on curve cross on top of the coincident constraint and these really don't matter. I did find following the example as given that one corner would have a point on curve only and then you needed either to add the coincident constraint of later apply a trim to properly constrain the sketch. You would probably only find out when you start to add dimensions or manipulate the sketch but you can trim or extend to correct the errant corner very easily.
Now perhaps it would be better if it was that little bit more robust. But then again I don't come across these problems that often so perhaps its not that big a thing.
Perhaps this thread ought be entitled things PLMS could fix. The idea that it "NEEDS" to be done implies that it can't be used or isn't fit for its purpose. Some things like the new hole feature in NX-5 had a few teething problems that needed fixing and were quickly responded to. Other things like this example could be easier to use but if used correctly shouldn't be that hard to live with.
Cheers
Hudson
JohnRBaker
Mechanical
Hudson,
I'm sorry, but I can't agree with you. There is virtually NO difference in the results if I create the sketch in NX 5 or NX 3 (in fact, I went back to NX 1 where we introduced 'Quick Trim' and except for the fact that back then we constrained rectangles differently than now, the results were virtually the same as NX 5). Granted, even if I pick in the exact same order the results may show that some constraints are assigned to different parts of the sketch, but that does not detract from the fact that in the end, as far as using the sketch for any subsequent feature creation tasks, they are identical in behavior and they contain virtually the same number and types of constraints.
Attached is a side-by-side comparison image of a sketch created in NX 3 versus NX 5, and except for the placement of a few of the details and the fact that in NX 5, since there was a point already at 0,0,0, I didn't have to manually constrain the arc center to be coincident with 0,0,0, the results are virtually the same.
Besides the order of creation and final distribution of the constraints, I have still NOT seen a single piece of evidence which shows HOW these differences would prevent a user from doing something in NX 5 that he was able to do in NX 3 or any other previous version of NX, and until I do hear of something that can be verified as such, I see absolutely NOTHING wrong with the way NX 5 constrains a Sketch, and to suggest that this is perhaps a 'problem' that we'll simply have to learn to 'live with' is ridiculous.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
I'm sorry, but I can't agree with you. There is virtually NO difference in the results if I create the sketch in NX 5 or NX 3 (in fact, I went back to NX 1 where we introduced 'Quick Trim' and except for the fact that back then we constrained rectangles differently than now, the results were virtually the same as NX 5). Granted, even if I pick in the exact same order the results may show that some constraints are assigned to different parts of the sketch, but that does not detract from the fact that in the end, as far as using the sketch for any subsequent feature creation tasks, they are identical in behavior and they contain virtually the same number and types of constraints.
Attached is a side-by-side comparison image of a sketch created in NX 3 versus NX 5, and except for the placement of a few of the details and the fact that in NX 5, since there was a point already at 0,0,0, I didn't have to manually constrain the arc center to be coincident with 0,0,0, the results are virtually the same.
Besides the order of creation and final distribution of the constraints, I have still NOT seen a single piece of evidence which shows HOW these differences would prevent a user from doing something in NX 5 that he was able to do in NX 3 or any other previous version of NX, and until I do hear of something that can be verified as such, I see absolutely NOTHING wrong with the way NX 5 constrains a Sketch, and to suggest that this is perhaps a 'problem' that we'll simply have to learn to 'live with' is ridiculous.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
John,
I'm not so expert on sketches as to be supremely confident that everything I say is correct. Out of interest in my own time I made an effort to check what is after all a simple thing to do. What I found mostly agrees with what you found. There was just one case that occurred which concerned me and it seemed more to more easily come by in NX-5.
If you could just read this next paragraph and tell me if it is correct?
If I understand it correctly there are two types of constraints that may exist at the corners either "coincident" shown as a dot, or "point on line" shown as a cross. Now if you have a point on line on both elements that meet in a corner each on the other then it should behave as co-incident. You can also have a coincident and a point on line at the same time since they're not contradictory. Importantly in a static display of the sketches one likely to be over the top of another and you can't really see what has occurred unless you analyze the constraints on each line and arc.
This may be what is confusing things. I was finding that when I get a result that looks like yours, which is to say one that appears perfectly good, that occasionally one corner would not be joined if you manipulate the sketch or change dimensions. That is the arcs would always change in radius and their endpoints would adjust but the length of one line might stay constant so that corner either overlapped or had a gap depending on how you changed things.
That part of it was my testing in response to the question about whether the constraints apparently being applied differently actually functionally differed. I went to the trouble of checking it out in NX-3/4/5 with dimensions on the sketches and that is what happened.
Now I also noted in any version but especially NX-5 that if you quick trim out the arcs in the corners and then take out the lines that you get all coincident corners. This was what I meant by saying we can learn to live with it. I don't think it is ridiculous to spend one's own time trying to learn something and to help others, to actually find a tip that offers an albeit marginally better result and to post it here.
I find that if you use it this way and it results in all coincident corners then there is no doubt that the sketch will be robust. I have some nagging doubts about the other results based on what I have seen. I even explained that in the case where the corner wouldn't remain intact that it was very easily fixed. And I challenged the other posters aggressiveness in insisting that it was more serious than I think it really is.
Sorry but I'm really not pleased with being called ridiculous, wrong is okay, we all have to live with the facts. If we're to be held up to ridicule for lacking knowledge then it is a real setback for the forum.
Best Regards
Hudson
I'm not so expert on sketches as to be supremely confident that everything I say is correct. Out of interest in my own time I made an effort to check what is after all a simple thing to do. What I found mostly agrees with what you found. There was just one case that occurred which concerned me and it seemed more to more easily come by in NX-5.
If you could just read this next paragraph and tell me if it is correct?
If I understand it correctly there are two types of constraints that may exist at the corners either "coincident" shown as a dot, or "point on line" shown as a cross. Now if you have a point on line on both elements that meet in a corner each on the other then it should behave as co-incident. You can also have a coincident and a point on line at the same time since they're not contradictory. Importantly in a static display of the sketches one likely to be over the top of another and you can't really see what has occurred unless you analyze the constraints on each line and arc.
This may be what is confusing things. I was finding that when I get a result that looks like yours, which is to say one that appears perfectly good, that occasionally one corner would not be joined if you manipulate the sketch or change dimensions. That is the arcs would always change in radius and their endpoints would adjust but the length of one line might stay constant so that corner either overlapped or had a gap depending on how you changed things.
That part of it was my testing in response to the question about whether the constraints apparently being applied differently actually functionally differed. I went to the trouble of checking it out in NX-3/4/5 with dimensions on the sketches and that is what happened.
Now I also noted in any version but especially NX-5 that if you quick trim out the arcs in the corners and then take out the lines that you get all coincident corners. This was what I meant by saying we can learn to live with it. I don't think it is ridiculous to spend one's own time trying to learn something and to help others, to actually find a tip that offers an albeit marginally better result and to post it here.
I find that if you use it this way and it results in all coincident corners then there is no doubt that the sketch will be robust. I have some nagging doubts about the other results based on what I have seen. I even explained that in the case where the corner wouldn't remain intact that it was very easily fixed. And I challenged the other posters aggressiveness in insisting that it was more serious than I think it really is.
Sorry but I'm really not pleased with being called ridiculous, wrong is okay, we all have to live with the facts. If we're to be held up to ridicule for lacking knowledge then it is a real setback for the forum.
Best Regards
Hudson
JohnRBaker
Mechanical
Hudson,
I said YOUR suggestion was ridiculous. Smart people say ridiculous things all the time. It's part of what makes life interesting.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
I said YOUR suggestion was ridiculous. Smart people say ridiculous things all the time. It's part of what makes life interesting.
John R. Baker, P.E.
Product 'Evangelist'
NX Design
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
A little different subject, but still Sketch related...
In NX5, I can deactivate a Drafting sketch and Hide the dimensions using Quick Pick or setting a filter for dimensions. Why do I have to activate the Sketch to do the same for curves? Shouldn't the Hide command work the same for all sketch entities that are shown when a Sketch is deactivated?
Tim Flater
Senior Designer
Enkei America, Inc.
Some people are like slinkies....they don't really have a purpose, but they still bring a smile to your face when you push them down the stairs.
In NX5, I can deactivate a Drafting sketch and Hide the dimensions using Quick Pick or setting a filter for dimensions. Why do I have to activate the Sketch to do the same for curves? Shouldn't the Hide command work the same for all sketch entities that are shown when a Sketch is deactivated?
Tim Flater
Senior Designer
Enkei America, Inc.
Some people are like slinkies....they don't really have a purpose, but they still bring a smile to your face when you push them down the stairs.
- Status
Similar threads
- Question
