NX5 WAVE best practices in complex assembly design 3

[potrero]

I tried searching the forum but couldn't find a good set of best practices for WAVE... so, I'm curious what people consider to be best practices for WAVE linking in complex assemblies.

For instance, is it recommended to create parts from start parts, thus establishing the WAVE links?

Or, is it a good practice to assemble the "skeleton" part (I know, it's not called a skeleton in UG, but the analog in ProE is a skeleton...) into the assembly, and make WAVE links to the applicable components?

Any other thoughts? Thank you.

 

[uwam2ie]

@potrero
depends on what you want...
IMHO the best way to work in complex assemblies to work with the so called skeleton/adapter modell ( control structure).
All reference / wave geometrie in one assembley tree.

 

[NXMold]

What I have found coming from ProE is that you cannot freely make references between parts in assembly. I model false bodies (example, the clearance hole for a pin) in the pin component, then link that body out.

If you try to make references like in ProE, you'll hang yourself quickly. Where proe regenerates through the model tree (all parts in one tree) top to bottom, NX regenerates each part, then the parts it references, then the parts those reference... easy to make circular references at first.

Therefore, with the example pin, you'd have to be careful about linking geometry into it. If you only link the false body out to other parts to create the hole, your golden. If you linked a mounting face in, trimmed the false body to it, then linked that false body out to the mounting part... crash. Hope that makes some sort of sense.

NX 5.0.3.2 MoldWizard

 

[hudson888]

Both ProE and Catia users would probably be familiar with a Skeleton file as terminology. The fact is that in neither case are they anything but an assembly with a different use in mind. In NX we're happy to use any terminology that you like as long as it is understood that the files are all just part files adding a component makes it an assembly and adding a sheet allows it to be used for drafting but it could start and finish life with any usage you chose, its still a part file.

My advice to you in that case is that you have choice and need to understand how it affects you. Try and experiment with a new part called a.prt. Open it and create a simple block. Open another new part called b.prt and add a.prt to it as a component. Wave link a solid body into b.prt from a.prt selecting the block. Now select the link in the part navigator and look at the information about that feature. When you have done that you should delete or suppress the wave linked body before proceeding to the next step.

Keeping going with the experiment by creating c.prt and adding b.prt to it as a component. Now wave link the block again and check the information about that feature.

What this is showing you is that the wave linked feature draws on a.prt to find the solid geometry and an arrangement in the part where the link is made. The arrangement expresses the position in which the link was made relative to absolute co-ordinates. You'll have noticed that after the second step only a.prt and c.prt were mentioned in the information listing. It is implicit that the position of b.prt is known via that arrangement, but all that the wave link really needs to know it the relative positions of a.prt and c.prt.

Now you should suppress of delete the wave link in c.prt and create another file d.prt. Add d.prt to c.prt as a component. Make d.prt the work part, and create a wave link body selecting the block from a.prt. Check the information and note what has occurred and suppress or delete the linked body.

If you make b.prt your work part you should also be able to add d.prt to it and go through the same process of creating a wave linked body from a.prt and checking the linked body information.

Having reached this point I think in a quick and simple experiment you have a framework for understanding the possibilities for structuring wave linked assemblies. As long as you maintain the assembly structure then the links remain viable, and it doesn't matter how deep the tree is it will still work. I would however advise against really deep assembly trees because as the number of dependencies increase so does the complexity the burden on the system to keep things up to date and the likelihood of errors.

Some people always place anything used in wave linking directly beneath the part where it is linked to. In so doing you can exclude the wave link donor part for reference sets and keep it off part lists etc. Best practice is a terminology that often means the lowest common denominator, or a way that will be most reliable. If that is what you want then you may chose to use that method. I prefer not to but I seldom design complex uses and re-uses of wave link geometry into my models to avoid unmanageable dependencies.

One thing I would always include as best practice is to assign a feature attribute to the wave linked body. I call it wave and the value is simply the part number it was from.
If you link a number of faces I keep them together in the tree or group them. You can assign attributes to more that one feature at a time. The purpose of this is because if the link gets broken, (sometimes I break them on purpose), then you have the information that you need to quickly re-establish the relationship by simply editing parameters and re-selecting the geometry that you need.

Lastly remove b.prt from the assembly c.prt so that it only contains d.prt. At least the last link that you made into d.prt will still be valid. b.prt still exists and contains a.prt and another copy of d.prt where that linked body was created. The instance of d.prt that you see added to the assembly c.prt now contains what some people call a sideways link and as long as b.prt is saved with that arrangement of a.prt and d.prt then the link can be maintained. That is a very complex method but as some larger OEM's use it you may need to be aware of the practice. In this case b.prt becomes an extra skeleton assembly that you need to maintain. I would have to add that NX users universally regard it as a pain in the neck.

If you're using some versions of teamcenter with vis-view then the JT files occasionally tend to capture the donor part for a wave link if it is placed underneath the model. There were complaints about one thing over the top of another at one stage which brought the sideways linking method into use. From my experience it may have been a lack of discipline rather than technical technique that caused the problem, so I'm not an advocate for it, but if you do use teamcenter and JT files for vis-view then do check that whatever you chose works properly with that.

There is one other case that you need to consider which is the linked mirrored geometry where all of the above applies but technically you need to have a datum plane to mirror about and most users would like to know whether to place that plane in the assembly part or the linking part. Technically it will work in either way just so long as you can select both body and datum plane to create the link. My answer for best practice is that the plane should exist in the same part as the wave linked geometry. The reasons are that it is easily found and you should label it with feature naming, attributes or both, and you can wave link via an arrangement in an assembly that you don't own (i.e. have write access to) and it will still work.

That ought to be enough to keep you going for a while

Cheers Hudson

 

[potrero]

Hudson,
Thank you so much for the in-depth post. I'm working through the examples you've given, and I have a question: I created parts a.prt and b.prt; made the cube in a.prt, and added a.prt to b.prt. Now, when I try to WAVE copy the body from a.prt into b.prt, I can't actually select b.prt as a valid component to copy to. Only when I create c.prt, and add b.prt to c.prt, can I create a WAVE link from a.prt to b.prt. Is this valid behavior? Is there some toggle that needs to be switched to enable WAVE links to the top level of an assembly? (By the way, the assembly navigator IS in WAVE Mode.)

Thanks,
Abe

 

[uwam2ie]

@hudson
your explanation is ok but in complexer situations and for traceability its the best practice to work with a control structure in asm. context. Its easier ...

 

[hudson888]

potrero,

you need to make sure that you have made b.prt your work part and that you have a.prt as the solid reference set. It should work, but I could imagine some site standards settings that might potentially get in the way. Let us know if you continue to struggle. It is a very quick exercise if in doubt you can probably afford to start again.

uwam2ie,

Traceability is what you make it. I pointed out at a couple of junctures how you might use attributes or naming to keep and handle of how you work. You have posted using terms like control structure or skeleton file which are commonly used in other CAD systems. I would advise not to expect to use NX in the same way it will only get in the way. What I would like to ask because your terminology is foreign is that you describe how you would go about creating assemblies with wave links. I think that I canvassed the options fairly thoroughly but if there's something I missed we're not going to know what you mean unless it is better described.

Cheers

Hudson

 

[potrero]

hudson,

I made sure b.prt is the work part, and a.prt the solid reference.

I think the problem was that I was trying to accomplish the link by right-clicking a.prt in the assembly navigator (then, "copy geometry to component"). With that method I still haven't been able to figure out how to copy geometry to the b.prt.

But, I CAN do it if I accomplish the link by doing an "Insert -> Associative Copy -> WAVE Geometry Linker", then select the body from a.prt.


Is this the way that you meant for the link to be done?

 

[potrero]

hudson,

After working through all the steps, I must say, your little tutorial exercise is very helpful.

I have a follow-on question:
Prior to removing b.prt from c.prt, the assembly structure looked like:

c.prt
___d.prt
___b.prt
______d.prt
______a.prt

where a.prt provided "seed" geometry to d.prt, b.prt, and c.prt.

Let's say that c.prt happens to logically be an assembly with two parts. For example, if c.prt was a plastic bottle, then let d.prt be the bottle body, and b.prt be the cap. If a.prt contains design sketches, seed geometry, knowledge, etc... that we want to have drive the bottle body (d.prt) and cap (b.prt), what should the assembly structure look like? Would it make sense to structure it like:

c.prt (bottle assembly)
___d.prt (bottle body)
___b.prt (bottle cap)
___a.prt (bottle knowledge driver part)

or like:

c.prt (bottle assembly)
___d.prt (bottle body)
______a.prt (bottle knowledge driver part)
___b.prt (bottle cap)
______a.prt (bottle knowledge driver part)

?

 

[hudson888]

potrero,

For your first question the second method every time. You used the menus Insert -> Associative Copy -> WAVE Geometry Linker and in fact I often describe it thus for new users, but I use the icon from the Assemblies tool bar.

As for the structure of the assembly I'm glad you're thinking about this in this way. Some people insist on using your second tree example but I really don't mind if you use the earlier example as long as you keep to a convention that you're happy with. In providing more information than you need I want you to have all the choices because that's how this system works. The moment you settle on something somebody else will do otherwise and you can often ill afford not to deal with it.

The real information that I gave you was about feature naming and attributes you need that to make your work traceable should the links get irretrievably broken.

Taking one step further with either example be sure that you can deal with whether your knowledge driver part doesn't appear on the parts list if you don't wish it to.

Cheers

Hudson

 

[potrero]

hudson,

I'm not sure how to exlude the knowledge driver part from parts lists. Can you explain how this is done or point me in the right direction?

Also,is there any overhead penalty to the second tree example, that would be caused by having potentially many more parts in an assembly (essentially 1+(n-1)/n more parts in a given assembly)?

Thanks!

 

[hudson888]

potrero,

after you create the parts list you select the parts list so that the whole thing is highlighted and use MB3 to bring up the editing options panel. Go into edit levels and all the components in the tree will likely be highlighted. By using a combination of control selection and shift selection methods and clicking on the individual components as listed in the ANT you ought to be able to select and/or de-select those which you want included or excluded from the parts list. You should be able to see the parts list update as you make those selections.

I think if you're unused to parts lists you'll first have to some to terms with some of the selection techniques that are used, but I don't know that you need that explained here and now.

Also as I may have mentioned earlier you want to remove from the reference sets any part that doesn't appear on the drawings or isn't part of the modeled assembly either. Now I'd have to add that many places consider it good practice to move such components to other layers labeled with that purpose in mind. Some people these days seem to have taken a set against using layers. I find that a fairly limiting approach, but whatever you choose to do have a convention and label things so that others will follow the convention.

Best Regards

Hudson

 

[potrero]

When linking entities from the "knowledge driver" to a component, is it recommended to (A) create reference sets encapsulating all the entities to be linked, or (B) link entities individually?

I've seen cases where you create a new part from the "knowledge driver" and select a reference set to seed the new part; problem was it seemed difficult to edit the contents of the reference set. This was a couple versions ago (NX3 I think) so maybe this has changed by NX5?

Further to this question, I don't really understand the comment I've seen in the NX documentation regarding reference sets "Avoid Reference Sets in Subassemblies". Would this tend to say that the answer is: best practice is (B) to link entities individually?

Also, @hudson can you comment on my question as to whether there is any overhead penalty to the second tree example caused by having more parts in an assembly?

 

[hudson888]

I don't know that it has ever been really difficult to edit the contents of reference sets provided that you know what you're about. Since I don't know anything about symptoms of what is going wrong then it is however difficult to comment. Having said that nothing comes to mind in terms of changes to the way that reference sets work from NX-3 to NX-5.

As to whether you add components that you use for wave linked geometry to you reference sets the only governing factor that I and I think most people would observe is the assembly integrity. In other words how you want the components and assemblies to display, I never want to see extraneous data layered on top of the actual components so that it becomes necessary to analyze what is the product as opposed to donor parts to wave links. We put them on a separate layer and remove them from any reference sets. Many Places create file organization utility programs to manage that for them. There is one natural exception I would mention which is that it is often the case that links are made with components that belong to the design and don't need to be excluded. Since you may be just starting out for things like machined weldments some people prefer to use promotions over wave links, but I'll leave you to read up on that as it is a matter of pure choice I would recommend in only a few special cases.

If you have a lot of entities to be linked you could filter them in a lot of ways of which reference sets might be the least preferred. For example if you do have an advanced assemblies license and the filter you need is a matter of selecting components then try component filters. Otherwise I would prefer to create the links separately. With reference sets remember create nothing you aren't willing to maintain, if you must do so temporarily then it won't hurt at all to delete them once the links have been created.

The Comment about avoiding reference sets in sub-assemblies is valid. I ought to write FAQ's in here one day given I've repeated a long explanation frequently. It is to do with assemblies at least three levels deep such that there can be difficulties in managing how the middle component retains its memory of which reference sets of the bottom component were displayed based on what you probably did in the top component given that is the only place that you can see the effect. Given that you might normally have two reference sets SOLID and REP and supposing you display the REP reference set of your subassembly and it should contain the bottom level component also with the REP reference set displayed, but you change the reference set in the bottom part to SOLID you will at the top level see the solid part. If you then save and having write access to the middle part or sub-assembly then the rep reference set will be saved with the SOLID of the bottom level component as its contents, which most people would agree is wrong. The problem with this is that it is frequently inadvertent and quite difficult to police.

With the question about the overheads it is not so much a case of causing any great problems with having more parts in the assembly if you work as I have recommended, since by removing them from the reference sets they should not be displayed or impose an extra load on the system on that basis. Most people working in large assemblies use faceted reference sets and partial loading anyway few ever load all the components automatically knowing that it imposes too great a load. One of the reasons for adopting a strategy that does not place the donor for wave linked geometry at a far flung point of the assembly from the wave linked bodies is to limit the components that need to be fully opened in order to update the links. You really need to fully open the components (or turn off partial loading before opening your assembly), in order for the update process to run successfully.

When working in smaller assemblies under lighter load some people prefer to set up automatic update of their assemblies upon loading and use all Solid geometry with no partial loading. If all your projects are small enough to afford you the luxury of working by that method then it will be the easiest way to go for you.

I think that is enough info for now to answer your questions

Cheers

Hudson

 

[acciardi]

Would anyone care to comment on the use of the context assembly used to create the WAVE links?

Let me back up a bit by stating that we use WAVE primarily to create models of castings that will have machining operations performed on them.

We create a 'context assembly' in which we assemble the cast model at 0,0,0. We then assemble a 'start part' (ie; an empty part with just a datum csys), also at 0,0,0. We then make the empty part the Work part, and WAVE link the entire solid body of the casting into the new part.

This has been working out pretty well with only a few exceptions.

We find that keeping the context assembly around is useful when using TcEng and swapping out different revisions of the WAVE parent and child. Without the context assembly, you have to go through this fairly confusing re-parenting process which has been only about 50% reliable.

We were told at one point that keeping the context assembly was optional, but without it I haven't found a robust way of swapping out a newer WAVE parent for an older one.

Ed

 

[hudson888]

Ed,

You're dead right there I don't think you need to change anything about what you're doing. Some people use promotions instead in you circumstances but there is no real need to do so as long as you're managing now. Also a lot depends on your system as to whether you assign a different part number to the casting and the machined part. Re parenting or at least properly separating wave linked components using teamcenter has some affect to the way the database also manages the dependencies between different items. For that reason you're better to stick to the simpler system that you described.

Best regards

Hudson

 

[acciardi]

Hudson:

Thanks for the input. We do in fact use separate PNs for casting and machining.

One more comment... some of our users have suggested assembling the casting model under the maching model, skipping the additional context assembly and essentially turning the machining into an assembly.

Can you think of any pitfalls of doing this?

 

[hudson888]

No it is essentially the same thing so long as there's always a maintained link you'll be okay. You should already know how to tackle this from a partslist point of view etc. I think its what most people do in that situation.

Cheers

Hudson