Windchill management of NX Wave links

[Dobi]

Hoping that someone may offer some guidance on this one but if the last NX question is any indication, this may go into the ether 🙂 

One of the CAD softwares we use is NX but our PLM is Windchill. Windchill supports certain types of references but not all per the documentation below. 

Managing NX References 

That's fine. I understand. My question is about "consequences". 

Say that we do in fact use "Wave links created using Routing Objects geometry" (if you're doing any sort of cabling, you will struggle doing it differently), how does that present on the Windchill end as far as collecting the appropriate models to add to workspace? 

A particular error we're getting is "Failed to save xxx.prt - file in use by another process". This is for a child of a fitting. If we add the entire family table (Windchill doesn't collect this on it's own likely because it's an unsupported reference) and make sure that it's not Locked in the workspace, things behave reasonably well within NX. If that's not done ahead of time, though, then the user has to click through the length of the family table's worth of "Failed to save" errors before the model will load. That's inconvenient at best and impossible at worst since some of these family tables can be pretty deep. 

Is there a way around this that isn't a "user must manually remember to collect all the family table instances" process? 

[avillanueva]

I am confused here since Windchill docs indicate support for family tables and NX. Which is the unsupported reference? You appear to be an experienced user but I have not used WGM for UX in many years. To your first question, Windchill will show references on the Related Object tab of the detail page. The reference type should be indicate there. It makes a distinction between required and all references in the collector. I need some more examples of the second question.

[Dobi]

The issue is with Wave links created during Routing. It's like the Harness module in Creo for running pipes/cables. There are external references to connection points and while the other reference types are supported, the links created using routing objects are not. 

I'll have to dig into whether these show up as references in Windchill specifically (it's a bit hard to track down with the model I'm using) but at first pass they do. The issue appears when we go to load a model. The fittings (in this case) are a family table and of that family table we use one or two instances. However, when the model loads we get a "failed to save" error for all of the other instances even though they aren't used in the assembly. I don't know how NX manages the routing and whether through it updating it's references it's thinking it needs access to the whole family or what... 

In the end, whether Windchill manages a reference or not is secondary - in a way - because NX manages it and knows what it needs. It's a problem when the user doesn't know to collect all the things (even ones that aren't explicitly used in the model) because of an unsupported reference type. 

So far we have two workarounds:

- user collects ALL family tables irrespective of whether instances are specifically used

- during modeling, break all routing Wave links and fix the references (which, if references move is not great)

[avillanueva]

For the family table, which should be supported, all instances need to be loaded. Each instance is its own CAD document and reference should be managed uniquely to that instance. When changes are made to the family table, the general and ideally all instances are modified to ensure sync. That should be all that is needed.

When using a member of that family table, NX should be looking for a specific instance. You should get the general and any instances referenced to download to the workspace. If it fails to pre-download those and add them to the workspace, does it not pull down on the fly? 

I am just trying to separate initial loading of an assembly and management of the FT. 

[Dobi]

The family table is supported and referenced correctly in that NX recognizes and looks for specific instances and that's what's added to the workspace. 

In this instance, I'm not changing anything... just opening the assembly. 

On open, as it's updating the links in the assembly NX starts throwing "failed to save, used by another process" error for all of the other instances that are not in the workspace. Once it goes through that family table - which happens to be the table that 2 instances are used from with wave links from routing objects - the model opens and the we can work. 

[avillanueva]

Am I correct is saying that NX is trying to touch or modify the instances to update links? That would mean the links are stored in the component model right? At the time of opening, are the instances all download? Are they locked in the workspace by default? 

[Dobi]

That's where all of this is stretching my knowledge of how this behaves. 

The assembly is using 2 out of 12 instances and that's what Windchill shows. These instances use wave links from routing objects to be placed in the assembly. When I add the assembly to the workspace, it adds the generic + 2 instances Windchill knows the assembly is using. So that's good. But the other instances are not added/downloaded since they aren't used. Again, expected.

And yes, we have a preference to auto-lock on add... long story but it's staying for now. 

Here's where I get confused then:

When NX is using wave links with routing objects, does it want to touch or modify ALL instances of a family? If yes, why? And if that's the NX behavior, is that what Windchill isn't supporting? It knows of other wave linked references but I'm assuming that it can't distinguish between Wave linked objects and Wave linked objects from routing. If NX stores the routing object links differently at the component level, then ok... I get it. Not ideal and my workarounds, though painful, work. 

[avillanueva]

Try this as a test. Before you download the assembly, download all the instances to the workspace. Leave locks on like you have. Any issue opening that assembly now with all downloaded? If no, then change your collector to download all instances by default (this can be done in site preferences for all users). 

If yes, try same thing but this time have instances and generic unlocked. Did NX modify the instances? Did the assembly open cleanly? 

In Creo, I have seen issues (not Windchill related) where FT instances were not saved right. Creo just by opening was indicating that they were modified. In this case, it was calculating a parameter via a relation which caused the value to change. It would complain since the object was read only. We resolved it by fixing the issue with the instances such that they opened and remained unmodified and read only.  Let me know if this better.

[Dobi]

I'll give that a try. NX is definitely wanting to do something with all the instances. 

I exported out the assembly and opened it offline just through NX without Windchill in the picture and it seems to resolve just fine without the need for the instances. So this is some sort of Windchill thing...