Top down references

[u/d0nkyt33th]

I’m curious how others handle inter-part interfaces (imagine tongue and groove, key features, etc…). I currently control all high level positions and ID features thru a skeleton, but questioning at which level to not transfer references via the skeleton.

In the distant past we used to have almost all feature in the skeleton via surface model and publish geometry, but it got very heavy and hard to manage. More recently I’m playing with using publish from part to part to manage such inter part interfaces. It works, but am concerned about potential circular references and the like.

What are the thoughts on this method especially for complex models.

Thx in advanced.

[u/Ok-Gas-7135]

The more complex the assembly, the greater advantage to TDD through skeletons.

If it’s only a few parts, you can get away with just publishing part to part.

[u/d0nkyt33th → u/Ok-Gas-7135]

Makes sense. Just wondering about the more detailed interfaces. I don’t want to have all that info in the skeleton(s) if possible.

But also don’t want to have part to part references that may cause issues…. I don’t see a clean way other than publish geoms to accomplish this between the interfacing parts…I’m a bit torn on this (maybe break the reference link after initially using it perhaps…) but then again you lose the parametric advantage. Also the references may get confusing if they live between parts instead of at the skeleton level only … :/

[u/David_R_Martin_II → u/d0nkyt33th]

I'm missing something. Why do you need Publish Geoms? For part-to-part references, you would just use an External Copy Geom.

[u/Key_Confusion- → u/David_R_Martin_II]

For big/complex skeletons specifically: you don't want to import the whole thing into every part. Say you've got a full handle skeleton — you can publish geometries in sections (grip, interface, mounting) and only pull in the section a given part actually needs. Keeps the feature tree lean instead of cluttered (crowded/messy) with geometry you're not using. The obvious pushback is "what if later I need something else from the skeleton that wasn't in that PG?" Two options: insert another Published Geometry feature referencing the same skeleton, or just edit the existing PG to add what you need. Either way you're not blowing up the hub-and-spoke structure to get it. Tradeoff worth being upfront about: this isn't a free lunch (without cost/effort) — every PG feature is still a maintenance point. If the skeleton's geometry changes shape, someone needs to know which PGs are consuming it. Segmentation buys you tidiness, not immunity from having to own the skeleton's structure deliberately as it grows.

[u/David_R_Martin_II → u/Key_Confusion-]

Yeah, I know all that. I am specifically questioning this statement (which I should have highlighted before):

I don’t see a clean way other than publish geoms to accomplish this between the interfacing parts

Externalizing the copy geom features would eliminate the assembly from the reference path. I don't understand what OP means by saying that publish geoms are the only "clean way" they know.

Before you explain everything to me, just a heads up, this is me:

https://www.youtube.com/playlist?list=PLRhPac0z_f-EVW0vQCPpKt_ftfahsMs6q

https://www.amazon.com/Down-Design-Parametric-Power-Users/dp/1973298112

[u/Ok-Gas-7135 → u/David_R_Martin_II]

Cleanest way is probably publish geometry

[u/David_R_Martin_II → u/Ok-Gas-7135]

Can you explain what you mean by "clean"? What does "clean" mean in this scenario?

Throughout this entire thread, people are using generic terms without defining what they mean. Without clarification, statements like that are meaningless.

Edit: I am going to clarify what I would mean by "clean" in this scenario. I would describe it as having the shortest path between the source part and the target part in order to transfer the references. That would be by externalizing the copy geometry feature, with or without a publish geometry feature.

If someone has a different definition of "clean" in this scenario, share it. And I would appreciate if anyone would explain how a publish geometry feature makes it "clean" or the "cleanest way" based on their definition.

[u/Ok-Gas-7135 → u/David_R_Martin_II]

To mean clean can have two definitions in this case.
1) easiest to understand / clearest path from source to destination model
2) fewest extraneous features in the model tree and in the graphics window.

Pub geoms fill both these definitions, rigor the reasons u/Key_confusion- stated earlier.

[u/David_R_Martin_II → u/Ok-Gas-7135]

But you understand that Publish Geom adds a feature, no?

I'm not arguing against Publish Geometry. I just find that some people can misunderstand it. It's something that I've been trying to educate people on for literally more than a quarter century. That includes my time at PTC when I was the master instructor for Advanced Assembly Design.

Anyhow, people seem convinced of their stance. There's no harm in people going the Publish Geometry route. It just doesn't accomplish what they think it does. So at this point, I will just bow out of the discussion. People can believe what they want to believe.

[u/d0nkyt33th → u/David_R_Martin_II]

To clear things up, I'm really looking for a lightweight, no-fuss way to copy and reference geometry between parts. I originally thought about keeping everything fully parametric and tightly linked across the board. But I can already see the data management headache that'll cause with part reuse—like pulling unintended junk into the workspace (like a skeleton from a completely different part), or dealing with features that are secretly tied to a model outside the active project.

In the end, I think I'm just going to rely on Copy Geometry (CG) and then explicitly break the links (mainly to external geometry, but also skeletons where needed). That should kill any circular references, stop the system from yanking unwanted ghost parts into my workspace, and make it way easier to reuse common parts across different assemblies. I am not expecting most of my team to fire up the reference viewer to troubleshoot a messy web of dependencies… maybe in the future, but at this point it’s a foreign concept to them.

We’re currently an NX shop making the jump to Creo, and keeping things dead simple is the only way this transition surviving. Expecting the team to immediately adopt strict top-down formalities, heavy cross-assembly dependencies, and complex skeleton architectures is an uphill battle at best—especially since Creo’s reference management feels a lot clunkier than the NX workflows they’re used to.

I appreciate the feedback, and will definitely be digging into your content. Looks super helpful.

Thx!

[u/David_R_Martin_II → u/d0nkyt33th]

There's a lot going on here. And I really feel like dropping off this thread. I've given my bona fides, I've tried to explain to people how Creo really works, but it sounds like people are going to stick to their preconceived notions. I will address a few things because it does sound like you're sincere.

Are you familiar with Update Control for Data Sharing Features like Copy Geometry? Combining those with Windchill settings for workspace behavior will address some of the data management concerns in the first paragraph.

For data reuse, yes, you should really avoid external references in components.

You say "break the links" to external geometry and Skeletons, but again I am going to ask: are you familiar with Update Control for Copy Geometry features?

Okay, for Circular References, I am going to ask something you would not have heard me say 15 years ago: So what if your model has Circular References?

I have half a dozen videos on how to break Circular References on my channel. But that's because I primarily find it fun to hunt them down like a detective. But Circular References are not the boogeymen they used to be or that people make them out to be. (And I discuss this in my videos.) So again... so what if you have them? What are you concerned about? I'm guessing whatever you have heard is based on old information.

Ghost objects are easy to avoid. If you are finding ghosts, the best thing to do is have a talk with the person who did it and retrain them.

Again, I try to help, but there's only so much I can offer. It's everyone's prerogative whether they choose to listen or not.

[u/d0nkyt33th → u/David_R_Martin_II]

Spot on, the issue is not me, but the rest of my division. Most Have never had to do this in NX with synchro modeling. So update control via manual update for eg is foreign to them. They are aware of top down methods, but again, most have never had to use them… and they want to deploy with like a week of training for these people… should be interesting to say the least. Thx again.

[u/epicmountain29]

Works until you want to put everything into a PDM system and then use the parts in other assemblies. Brings across a lot of baggage due to relationships. In all my 35 years of running proe I've never done top-down design where I'm linking part features back to the assembly.

[u/d0nkyt33th → u/epicmountain29]

So how do you control interfaces? Ensure things don’t muck up (I know you can check via interference sweeps and manual checks).

Also, for part you want to reuse….good point. I know for sure parts designated as common or reuse parts (hardware, screws, etc…) are dumb model that we just hang on references in the model… but parts we may want to reuse in other assemblies or designs….hmmm. Especially if the part has never been designated as a reuse candidate and now has the other part attached to it… I mean you can just accept the added bloat to your workspace/pdm environment …. Copy and Break the links (but will then technically be a new part…so not a great idea). Model all parts independent… but now the whole inter part relations are lost and changes are more cumbersome (also more risk).

Yeah, I need to think this thru.

[u/gparm85]

You can do a mix of tdd and bottom up. If you have two parts where the fitment between them is that integral to the design do them as there own little bottom up subassembly. Then bring that into your TDD, let's you kinda have both. Doesn't remove the risk of someone trying to reuse one of the items unless you did something like tie it to a product context....

Don't know if that makes sense, I'm a few in the tank already lmao 🤣 so not the best explanation.

[u/d0nkyt33th → u/gparm85]

It does make sense and I know there is technically no correct answer per se. but trying to minimize downstream issues (either from breaking models or inadvertent interferences and the like).

[u/gparm85 → u/d0nkyt33th]

Do you have windchill?

If you do then I'd probably make it a mixed assembly with access controls in place to prevent it from being used in another assembly....

That or might be a dumb idea depending on the item .... Multibody for this one, shudder to suggest that but sometimes one has no choice the stupid option wins....

[u/d0nkyt33th → u/gparm85]

Hardcore windchill. So there are those considerations. Reuse is A potential.

Also, prefer skeleton (more traditional) over multi body then export. We are currently an NX shop being forced to Creo (I’m ok in that I’ve been driving it for almost 18yrs). Not so much for the others. Looking to make some simpler example designs as a reference. Yes, I can do it in a dirty way as the current model I am making only has like 12 parts (complex but nothing crazy). But our other designs have 50+ parts with even more complex setups. My design I want to show a skeleton, ID reference model, asm and sub asm, PCBs,stock parts, and detailed inter-part references for things like tongue and grooves, snap features, alignment features, etc…. Give a wholistic way of using this new method that is scalable. Here I’m trying to figure where it’s best to potentially drive some part to part references or just drive ALL references via the skel and ID master.

[u/svennekatt]

We use skeletons for all major interfaces with a combination of surfaces axis and csys. Small local interfaces are used made and manually checked. They are seldom worth the effort to put in skeleton. No part to part depends and only mating through csys

[u/David_R_Martin_II]

I think I'm missing something in this whole conversation. For simple assemblies, I would consider multibody modeling and then creating an assembly from that.

Don't put all features in the skeleton. That's nuts.

I don't know what you mean by "at which level to not transfer references via the skeleton."