Showing results for 
Search instead for 
Did you mean: 

associativeness of measured value


In my mind, the measuring tool for value input always gives associative results. In mose cases it works fine. But today I find that non-associative result is also possible.


This makes me greatly concerned about the use of measuring tool for value input. Your suggestion would be highly appreciated!


ScreenClip.pngFig.1 The 1st point (10, 30, 0).ScreenClip [1].pngFig.2 Building a 2nd point by offsetting the Origin.ScreenClip [6].pngFig.3 Offsetting distance comes from measuring the height of the 1st point.ScreenClip [3].pngFig.4 In the Distance box, value "30.0000" has a ruler icon on its right. OK to finish buiding the 2nd point.ScreenClip [4].pngFig.5 But the new expression "p3_distance" is not a "Measurement"! Apparently the 2nd point is NOT associated to the 1st point.ScreenClip [5].pngFig.6 In my past experience, values from measuring tool should looks like this. They are associated to the measured objects.



Re: associativeness of measured value


It seems that Measure within a command can't be associative. Maybe Siemens could consider adding this functionality. Thanks!

Re: associativeness of measured value

Siemens Phenom Siemens Phenom
Siemens Phenom


surfactant_pub --


Measurements are one of the areas I look after in NX.


To clarify, measurements within commands most definitely CAN be associative.  :-)  In fact, they are associative by default.  Try similar mesaurements embedded within Extrude or Hole features, and you'll see what I mean.


With that said, there is certainly something odd going on in this specific command. The *first* time you (or I) attempt this offest for the second point, the Point command is creating this odd non-associative value.  (I'm seeing what you saw.):


NX 11 first time


Interestingly, editing the second point and performing the measurement AGAIN actually results in an associtive offset:

NX 11 second time


Go figure.  Given that I don't see that "double-pump" behavior in any other embedded measurement scenarios I've tested, I suspect an anomaly in the Point feature.  Submitting an IR there would be very helpful.


I can tell from your Expressions dialog that you're in either NX 11 or NX 12.  Out of curiosity, I went back to NX 10 and tested this, and was surprised to find the exact same behavior there -- namely, a non-associative result the FIRST time...


NX 10 first time


...and the associative result I would expect the second time around:


NX 10 second time


So this is clearly not a new anomaly.  Again, an IR against the Point function would be helpful.  (...and feel free to reference this thread in the IR.)


One last thing...  Note that the measurements taken from *within* another feature are represented in the expressions dialog differently than measurements taken as their *own* feature.  (In fact, they're architecturally slightly different under the hood as well.)  Embedded measurements will show up with this black string [which is more susceptible to inadvertent editing] in the formula -- as shown above -- and standalone measurement features will use the blue "system" expression style.  (...and as you can see from the NX 10 pictures, this has been true for quite a while.)  If you're aiming to remove potential points of failure, creating standalone measurements ahead of time would be a slightly more robust way to construct this.


Thanks for the good observation!

Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Tel: +1 (602) 441-0683

Re: associativeness of measured value


Hi, @TaylorAnderson


So good to have your very informative reply. Thank you!