cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

Auto-associate for multi-CAD files

Dobi
16-Pearl

Auto-associate for multi-CAD files

There was a past thread with a similar topic here. I felt my ask was a bit more nuanced so...

 

We have Creo and NX files. They both, unfortunately, end with .prt for the CAD models. In the library, there are a large number of Creo family tables that are of standard things like nuts, bolts, o-rings, etc. I'd like to add in the equivalent models in NX. 

The idea is that our NX models can consume NX library parts. Creo models can consume NX library files (assuming CS134024 compatibility is observed). So it makes sense that library files in general are in NX since Windchill doesn't do multi-CAD the other way around when Creo is not the driving CAD (i.e. NX cannot open and consume Creo files through it's "native" WGM Windchill interface). 

 

So now, I have a WTPart with a name and number driven by the Creo CAD. I'd like to have my NX CAD auto-associate to the existing WTPart but I can't have the number and file names be the same as the Creo. 

The filename can be different despite the filename extension being the same (o-ring.prt and o-ring-nx.prt). However, the number field also has to be unique. I can't have O-RING be the number for both.

Is there a way to make the auto-associate rules in preferences auto-remove or truncate a -nx at the end of number and then auto-associate as "image" to an existing WTPart? 

ACCEPTED SOLUTION

Accepted Solutions

It looks like I got lucky on this one... 

Namely:

 NameNumberFilename
Creoduplicates allowedAS568-dash-material.prtAS568-dash-material.prt
NXduplicates allowedAS568-dash-materialAS568-dash-material-nx.prt
WTPartduplicates allowed

AS568-dash-material

since the original file extension was dropped 

NA

 

So I was able to create an NX part family with it's own and unique file names and matching names to the WTPart. For the number, I just dropped the .prt and then was able to auto associate as image the NX CAD to the existing WTparts... 6000 times. 

 

Where it got a little bit complicated is in how Windchill manages NX part families and which attributes (Name and Number) are set in Windchill vs. CAD. Luckily, the renaming wildcard rules in Windchill were flexible enough for me to in bulk (300-file chunks) remove the initially autogenerated -nx.prt extensions from the name and number so that everything played well together... 3 days later.

View solution in original post

2 REPLIES 2
HelesicPetr
22-Sapphire I
(To:Dobi)

Hi @Dobi 

It is complicated. You need to decide how the nx files should be saved in Windchill based on general rule that filename and number have to be unique

 

I can see one option that can solve your issue you just need to think how the identification of object will be kept

you can overwrite OOTB behavior to search WTPart for auto association.

HelesicPetr_0-1697003098604.png

Create own logic if the object is NX type and search by your own criteria. 

 

PetrH

 

It looks like I got lucky on this one... 

Namely:

 NameNumberFilename
Creoduplicates allowedAS568-dash-material.prtAS568-dash-material.prt
NXduplicates allowedAS568-dash-materialAS568-dash-material-nx.prt
WTPartduplicates allowed

AS568-dash-material

since the original file extension was dropped 

NA

 

So I was able to create an NX part family with it's own and unique file names and matching names to the WTPart. For the number, I just dropped the .prt and then was able to auto associate as image the NX CAD to the existing WTparts... 6000 times. 

 

Where it got a little bit complicated is in how Windchill manages NX part families and which attributes (Name and Number) are set in Windchill vs. CAD. Luckily, the renaming wildcard rules in Windchill were flexible enough for me to in bulk (300-file chunks) remove the initially autogenerated -nx.prt extensions from the name and number so that everything played well together... 3 days later.

Announcements


Top Tags