best practice for csys & other feature display mgt in assemblies & subassemblies

[potrero]

NX8.0.3.4 MP9 Win7 x64

I've searched the forum for related posts but couldn't find a concise answer to this very old issue: what are the best practices for use of coordinate systems (CSYS) and other datums/sketches/etc inside assemblies and subassemblies (as opposed to piece parts), particularly with respect to display management?

Some context:
1. It is a well known best practice to only use Reference Sets to control in piece parts, and not in assemblies. Reference Sets in piece parts are a great way to control the display of information, for example to only show the MODEL and not all the datums, sketches, etc.
2. Often it would be really convenient to have datums in the assembly file, for example: to aid in constraints of components or subassemblies.
3. But since the best practice has been emphatically and repeatedly stated that we should NOT use Reference Sets to control display of assemblies and subassemblies, the presence of any Features in these files creates display issues (ie the display gets rapidly cluttered with non-geometrical data like csys, datum planes, sketches, etc).

Some solutions:
1. Ban the use of csys and other Features in any assembly file. This approach conclusively solves the display management issue of subassemblies since there isn't any data to display. Downside is that you can't use csys or datums for constraints, or anything else you might want to do with these features.
2. You could use Show and Hide, but this approach is dependent upon the saved state and also depends on the subassembly level. (ie: the display will open by default in a noncluttered way for a top level asm, but if you open up a subassm that hasn't been saved with the desired view, then the user has to do a Show/Hide operation etc. Clunky and annoying.)
3. Control display of datums in assembly files with Layers. I haven't tried this approach, mainly because we don't actively use Layers at all in NX, and based on reading many threads on this forum, it's not clear that Layers are a recommended way of working. A concern is that people will not know that geometry exists since it is hidden on some unknown layer.
4. Some other even better way?

We currently use Option 1 and invoke Option 2 if someone breaks the ban and includes pesky csys's somewhere in a subassembly file.

Does anyone have a solid set of best practices for this issue that they've proven over time to work well?

Thanks for your help.

 

[JohnRBaker]

I personally go with #1, and when asked, that's also what I recommend for others.

As for constraining Components in an Assembly (whether it will ever be used as a sub-Assembly or not) generally speaking, the best practice is to place first that Component which acts as the 'foundation', the one which most other Components will be constrained to, and make it 'Fixed'. Also if there are other Components which don't touch any other Component and which some might say these are the ones where constraining to a local CSYS might have been appropriate, remember there is nothing stopping you from having more than one 'Fixed' constraint in an Assembly, something that was NOT possible with the old Mating Conditions but which is perfectly normal with Assembly Constraints. Also you might want to look at the 'Bond' constraint when you want to locate one or more Components relative to another Component but again they don't necessarily touch just that once you manually position them you want them to move with that first Component. And to that end, there is nothing preventing you from creating a CSYS where it's convenient, then with the Move Component function, using the Motion 'By Constraints' method, to position the Component relative to the CSYS noting that NO actual Constraints are created with doing a Move Component operation. Once you've got the Component where you would like it to stay, NOW use either a 'Fixed' or 'Bond' constraint to lock it down. Once everything is in place, simply delete the CSYS since nothing has actually been constrained relative to it so nothing will be effected by its removal at that point.

Anyway, give that workflow a try as it makes things so much 'cleaner' downstream.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

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

 

[41EX]

From the way NX works I would think it is better to use layers. To prevent the "hidden unknown layers", use categories of layer. A good practice would also be to predefine a range of layers for different objects (like 100-120 for datums, 120-140 for sketches, etc..)
I wasn't convinced at first but after a while, objects visibility is easier to manage with layers.
That's the way we work at the office and it seems to do the job well.