NX Error: "Part is not a valid version of component part"

[bistromathics]

I've got an assembly that complains about 2 of it's dependencies when I open it in NX6 or NX7.5:

4222-245-71640.prt - Part is not a valid version of component part
4222-240-06490.prt - Part is not a valid version of component part

These two components remain unloaded. I can open them individually with no errors and am trying to understand what the problem is. Searching google provided very few results, all from non-english sites, so I thought I'd turn to this forum which has proven very helpful in the past.

I am wondering if it is at all related to the version of NX used to make some of these components, as this data is all very old. One of the failed parts was authored in "Unigraphics V18.0.4.2" and the other was "NX 4.0.2.2", according to their 'part history'. My plan is to try and resave this data in a newer version of NX, but I wanted to post about it here to get some feedback and also so google has at least one instance of an english post for this error message.

 

[teookie]

I've experienced this error, and my best guess is that the assembly file has certain bits of data stored in it about each component. If, while loading a component it notices a difference between this data and what it is loading, it throws the error (because it thinks the component is different or changed in some way that makes it incompatible with the assembly).

Some possible fixes:
1) rename the component on disk and then open your assembly. You'll get an error that those components were not found but that's ok. Open the assy navigator and use the "replace component" command on your problem components, selecting the files that you previously renamed. This -should- load the components into your assembly.

2) If that doesn't work, just delete the components out of the assembly and then add them in again from scratch. Only problem with this is you'll have to reposition them and reassign all the assy constraints.

Hope this helps.

 

[bistromathics]

Thanks. Resaving the individual components in NX6 didn't fix the issue, so I'll give that a try.

 

[Singsonite]

Did you check your Assembly Load Options to see if Allow Replacement is checked? That usually fixes the problem for me.

John B. Conger
Tool Design
Automotive Interiors
Advanced Engineering Solutions Inc.

http://www.advancedinternational.com/

 

[wackolacko]

The reason for the error is because those files have a different UID (Unique Identification Number). Every file in UG/NX when created has an 25 digit(i believe) random UID number internally. So if you create a new file called xxx.prt and then create another new file called xxx.prt they have the same number but their UID's will be different. As John B. Conger said by turning on 'Allow Replacement' in load options NX will allow the component to load even though it see's a different UID.

John Lackowski
NX Support
Win 7 64bit NX 7.5.4.4 TC 8.3.1.1

 

[bistromathics]

Thanks guys - with the Allow Replacement option turned on, the parts do get loaded in session; the error still pops up though. Will saving the assembly with the replaced parts fix that for good?

 

[Singsonite]

It should fix for good. Yes.

John B. Conger
Tool Design
Automotive Interiors
Advanced Engineering Solutions Inc.

http://www.advancedinternational.com/

 

[Toost]

I would guess that there are two files with the same name in different directories.
Since you are running in "native mode" (?)( i.e not under Teamcenter) NX needs to find the parts somewhere, This is where the load options directory spec come in to play.
If NX finds when loading the correct file name but the wrong UID, = message above. ( If the "find order" is reversed = no message) It searches the directories in the order that they are specified under "Search directories".

* If you are running under Teamcenter this can still happen, but then somebody has been deleting and creating a new Item with the same Item Number, and the UID is again different.
- There are customer default settings for Teamcenter integration mode that can help in that case.

As John B Conger notes, if you load and save the assembly , it will store the other UID. Fixed until you change the search order...

Regards,
Tomas