Odd NX assy navigator behavior with Windchill

[Dave_K]

Version: Windchill 12.0

Use Case: NX 2206 Users will open a large, top level assembly as "structure only", then expand 1 or 2 sub-assemblies, and the assembly navigator will jump to display a different sub-assembly, and NX becomes essentially useless.

Description:

User opens a large top level assembly, using "structure only" in NX.  Then the user will expand 1 or 2 sub-assemblies, and the Assembly Navigator will change to list a different sub-assembly, and the NX session becomes essentially useless.  You can click on things, but navigating the assemblies or parts, is non-functional.  Sometimes a fatal, or other error follows.

Top level assembly is just under 30gigs, and it is all in the local workspace.  Loading "structure only" should only be loading a minimal amount of data into the NX session.

Everything functions as you would expect, if you run an NX session disconnected from WGM.  I've done this by running a second NX session, which fails to connect to Windchill.  Then do the same load, and assembly expansion in both sessions at the same time.

Also, load time is about 10X faster, when not connected to WGM.

In this image, you can see that the NX session connected to WGM is showing one part number in the tab, but a different part number in the Assembly Navigator.  Compared to the stand alone NX session, which shows the matching tab and navigator column.  NX session connected to WGM also experienced a Fatal error.

We are looking for any insight on how to solve this issue, as it is limiting, and slowing our productivity.

[Dobi]

@Dave_K 

The c0000005 error (when I had it popping up a few times 2 years ago) had to do with the registry being somehow corrupt. It was a difficult thing to reproduce but essentially boiled down to a stuck WFS service that had to be force uninstalled/removed with a Microsoft uninstall utility. I had a ticket with PTC on this and the recommendation was to:

- reinstall after the registry cleanup

- delete the %Appdata%/Local/Siemens folder

- run WGM as admin to first connect NX to it

- run per usual and hope for the best

Large assemblies will always run way slower in a stand-alone session than when connected to the WGM. Do you have any anti-virus software running? This may help: https://www.ptc.com/en/support/article/CS50545

We also have some other monitoring software that I had to exclude NX (ugraf.exe) and WGM (uwgm_client.exe) from to help the slow loads along. Our assemblies are in the 7GB range and with load_options.def file set to partially load + anti virus exclusions we got down to about 4-5 minutes instead of 15 without. 

There is a known "feature" in WGM that will cause major slowdowns too that has to do with mass reporting. Do you have mass reported from NX (NX_Mass via MassPropMass and MassPropRollupMass) to Windchill with the MSP:Mass mapping PTC suggests? https://support.ptc.com/help/windchill/plus/r12.1.2.0/en/index.html#page/Windchill_Help_Center/WWGMforNX/WWGMNXAdminConfigMappingwithUnits.html# doesn't point out that if there are modeling errors in NX that NX happily resolves - they seem to trigger mass calculations on the Windchill side for the number of errors that exist. Specifically: if you have pk_topol errors showing up in your syslog, you can go from a 30second load/save to 15-20 minutes. 

In NX if you do "Examine Geometry", "Feature replay" and "Part cleanup" it may help at least identify this. But there isn't a fix yet on Windchill not triggering a save even when you don't want one. The only thing I was able to do was remove the MSP:Mass mapping for NX_Mass until there's a fix in some newer version of WGM. 

[Dave_K]

If it is corrupting the registry, I'd consider this issue to be much more serious, as it is involving more and more users.  It was one in late July, and at least 6 now.  The issue also comes and goes.  The first user with the issue changed his assembly load options from "partial lightweight" to "Partial loading" (still structure only), and the issue went away for almost 2 weeks, before returning.  But, if it is registry related, why does it only affect NX sessions connected to WGM?  Also, we don't always get the c0000005 error, sometimes it's "an invalid tag was passed to the tag module", or "memory access violation".  I think we always get a "failed to get column value for column DESCRIPTION" error though.

In our case the native NX session is MUCH faster loading than, than the session connected to WGM, I'm guessing that was a typo?  We do have anti-virus, and other monitoring tools in place, I'll dig deeper into that.  Yesterday I recorded an NX session connected to WGM, and a stand-alone, side by side, and performed the same functions.  Stand alone was done in a couple minutes, and the session with WGM took half an hour, then had the assembly navigator issue, which also renders the session useless.

OK, that "feature" could be part of it.  We do have mass reported from NX, and I have noticed NX performing saves, while opening parts, and we wondered why it was saving.  I haven't noticed any pk_topl errors, but I will keep an eye out.  Thanks for the anti-virus tips, I will pass them along to IT.

[Dobi]

Hi @Dave_K 

After going through my notes last night I realized I confused my errors. 

e0434352 - Registry issue with a stuck (or somehow not functioning) WFS. The PTC ticket I had on this essentially claimed that this was fixed in NX2206 and beyond versions of compatible WGM. So I apologize for that mix up there. I only had this occur on a NX1956 system upgrading to NX2007 lots of times (I'm the admin so lots of back and forth installs and uninstalls). 

c0000005 - This came where a user was opening files from a workspace that wasn't sycned and updated. I did have to wipe the %appdata%/local/Siemens/NX2007 (that was our version) folder and it went away. It also went away in a clean workspace with freshly added latest files. I didn't feel like this was resolved to my liking - if at all - because I had no mechanism to reproduce the issue and figure out in more detail what was going on. 

Siemens claimed that in the end it was most likely the issue was related to older versions of files in the workspace. 

- part occurrence tree has been corrupted (possibly shadow part occ tree and real part occ tree are out of sync)

They suggested trying these environment variables: 

SET UGII_SHADOWS_FIXUP=1

SET UGII_ENABLE_LINK_FIXUP=1

And then loading the assembly fully and saving. 

In the other post you have on searching you say you have native-NX users... It may be the case where understanding how to properly sync and update workspaces when there are out of date flags is where you would at least want to start. It took a bit of time here to emphasize this practice and it still comes up often with the native-NX and previously TeamCenter users. 

Yes, correct: a typo. Stand-alone NX will ALWAYS load way faster than a connected to WGM NX. This is because of the background syncs of meta-data and such. Anti-virus exclusions and there's also this: https://www.ptc.com/en/support/article/CS46526

Once all of that was in place, the only remaining item that was a showstopper was the pk_topol_eval error in NX. In my internal testing and without that error in place, the load time is 3-4x longer in WGM. If we're talking a few seconds natively, it's a few more seconds in WGM. If you're talking 2-3 minutes... it can very quickly become unusable. 

The pk_topol_error was key, though in reducing any other time to as good as it can be. Depending on the complexity of the assemblies, it isn't hard to get. 

Siemens recommended (in order);

• Part cleanup (make sure everything is fully loaded and you select "work part and components". Select all checks except the "Serious Delete Actions" section)
• Feature replay - this validates that features are properly linked together
• Examine Geometry - to have a valid body, Data Structures, Consistency, Face to Face intersection and Self-intersection have to pass. If they don't, the user has to appropriately model geometries to make those issues go away. If you Select All here it'll highlight whatever isn't ideal

This is one of those items that PTC is treating as a bug because the pk_topol error will take seconds to resolve (per error) and you can have hundreds in a part ... so for an assembly it could take a long time to just open or save a file. 

[Dave_K]

So your comments on c0000005 are interesting.  I did some more reading about those env variables on the Siemens website, and it definitely sounded like it could be related.  Doing some testing with those env variables, I was able to open the top level assembly, and expand sub assemblies without issue, and I was able to consistently reproduce the error prior to this.  The one caveat, I synchronized the workspace before reading this thread, so which was it?  Testing will hopefully let me know.

@DobiI appreciate your insight, users of NX with Windchill seem to be rare breed.

[Dobi]

For my case, Siemens said that depending on the issues those variables might not help any... I did turn them on (and a few others) but it ultimately didn't matter because I - as a Windchill user - wasn't able to reproduce this once the workspace was cleaned up, synced and everything. 

I'd love to know if you figure out a more reliable failure mechanism!

Yeah there's not a large group of us but there's good info on best practices with NX and a few committed "I'll figure this out" folks". Sounds like you're one :). Often some of the Solidworks topics can sometimes be helpful too on the WGM side because of how the local cache is managed. 

I'm just in process of updating to NX2312 and WGM 13.0.2.0 and will try out that search path issue in load_options.def you had asked about a bit ago too.

[Dave_K]

I was a bit concerned about adding those env variables to the common ugii_env.dat file, since Siemens says UGII_SHADOWS_FIXUP should only be used once on a file, and they slow performance, due to cleaning up on file open.  I've also seen some of these "special" env variables cause other problems, especially when you forget they are in the ugii_env.dat file.

I wish I had a reliable failure method for this one.  It seems so random, that once I could reproduce it, after days of trying, I was a little excited, LOL.  Now with this being the first time the issue hasn't occurred since, I'm cautious to not get too excited.

[Dobi]

I didn't add those to the ugii_env.dat. 

Just put them in on my system directly because - like you said - it does slow things down and can also make the syslog giant. 

In the end, for me those didn't yield anything of consequence. 

[Dave_K]

Well, it may not have worked.  I had the original user with the issue try reproducing the issue, and he was able to, so no change in behavior for him.   So I went back and did some more testing, with, and without the NX env variables, and I can't reproduce it.  Argh!

[Dave_K]

@Dobi   I'm not a Windchill admin, so can you tell me where I would direct our admin, to turn this off?  "The only thing I was able to do was remove the MSP:Mass mapping for NX_Mass until there's a fix in some newer version of WGM. "

[Dobi]

@Dave_K  You want to go Site/Utilities/Type and Attribute Management. There, find the EPM Document item (under Manage types). Depending on how you have the system set you may have a Mass attribute at the top level or a level down (CAD Document). If you created any CAD document subtypes that inherit that value go to the parent.

In my case, MSP:Mass was defined at the CAD Document level:

This was in the details of the attribute:

Delete that line and save. 

That will have the consequence of your NX mass no longer reporting to Windchill. For us, this was preferred over a 15-20 minute save.