Wrong Feature Numbering

[man2007]

I have a part with 509 features, but the final Feature Number Shows up as 538 i.e. Blend(538). The starting number of features is zero i.e. Datum Coordinate System(0). Can anybody explain why this skip in feature numbering occurs?
This was not the issue when I was using NX2.
Now I am using NX 4.0.4.2., and facing this problem frequently.

 

[looslib]

There are usually hidden features generated along the way, especially with 500+ in the model.


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

Ben Loosli

 

[cowski]

If you (or a coworker) uses feature groups, this can hide some features in the tree. Also, if you delete features and then add new ones there will be gaps in the numbering. The system will occasionally renumber the features (eg when you reorder something) and that will set them right again. Reference this thread: thread561-238727

All of the above also happened in NX2.

Lastly, and I don't mean this to sound rude, what difference does it make? Is there some reason that you need a perfectly accurate feature count? The only reason that I can think of is if you were referencing the feature numbers to speak about the model, in which case it would be wiser to rename the feature(s) of interest to something more meaningful.

 

[joycejo]

I have seen this happen when you delete a feature and then add a new one. It really has no effect on the model. However if you want them all in a nice order you can create a feature like a fixed datum and re-order it to be the first feature and then re-order it agin to be the last feature. The other feature numbers will update. Then delete the unused feature and now you have a nice sequential list.

John Joyce
Tata Technologies
1675 Larimer St.
Denver, CO

http://www.myigetit.com

 

[jerry1423]

I do what Joycejo does. Usually my first two features are datum planes (or axis), I simply reorder the first two (in other words feature 1 becomes feature 2 and vise versa) and the entire tree will resequence.

 

[man2007]

Thank you all for your replies.

I got the "Reorder Feature" work-around from one of my colleague on the same day, which incidentally John Joyce also posted, thanks John.

Cowski,

Yes it will not make any differnce as such, but it will look odd when you see the model navigator, for example, I deleted all the features (containing 22 features) and started with datums, and first datum number was (22) !!

This is Bug from UGS.

 

[JohnRBaker]

NO, this is NOT a bug! It's just the way that it works now and the way it has worked since Unigraphics V8.0, which was released 18 years ago this month.

As features are created there's a running count kept of the numeric 'tag' which starts at '0' (there goes those computer guys again insisting that the first integer in a set is always 'zero') and is incremented as features are added to the model. However there is no attempt made to maintain, in real-time, a contiguous series of numeric tags with no gaps. As features are added and deleted, the count continues to increment, always moving up, in a relentless manner. There are several reasons for this, primarily in an attempt to minimize the impact on the interactive performance of the software due to avoiding any overhead maintaining a seamless count, potentially every time a feature is deleted or created. Besides, it was felt that having the numbers constantly changing could be confusing and distracting to the user. However, when features are reordered, there is no reason to even try and maintain any semblance of the old sequence of tags so we automatically do a compete re-sequence of the entire feature tree. Again, since there is no need to account for any gaps or local renumbering, but rather just doing a complete 'reset', the impact on performance is negligible.

Anyway, that's the situation and there are no plans to make any changes in this behavior. At best, we might consider adding an explicit re-sequence option, but again, we already have an easy to use, once you're aware of it, workaround so I wouldn't hold my breath.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Cypress, CA

http://www.siemens.com/plm

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

To an Engineer, the glass is twice as big as it needs to be.

 

[hudson888]

If ever there was something that actually is a feature and NOT a bug then this is the one. I don't much care how many features are in my model but what I sometimes to have to do is work back and forth through the tree to correct a problem and it is then that I want the numbering to stay put so that I can return reliably to a certain spot. It doesn't happen often but occasionally bend (132) in among a group of bends 119 through 143 is best and easiest found using the number even if I delete a bunch of features earlier in the tree.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum