Flexible reference handling in Top Down Design approach

[Jacek_Mydlikows]

Hello guys

I wonder how do you handle references between skeleton model and related parts to ensure the most flexibility as possible?

What I understand as "flexibility"?

* to me it is approach which ensures to you freely change of any entity in existing sketchers or even deleting them or even entire features without influencing final Publish Goemtry featutes which contains them

I start prototyping the product in Creo as soon as possible, making as much attempts and trial and errors I can.

This results often in critical changes, making whole idea of product, upside down, when simultanuesly appropriate Creo assembly is heavly advanced.

In such moment making significant changes is the first step to hell.

I hope I made my problem clear. So how dou manage references to let you change skeleton features without invoking every often solving problem of Public Geometry?

I found Datum Reference feature as some nice solution however it only helps to avoid regeneration problem of Public Geoemtry feature when single entities or quilts are removed not the whole features which represent them.

[dgschaefer]

Perhaps I am hearing you wrong, but it sounds like for you flexibility means being able to change without feature failures.  I'll push back on you and say that the flexibility you want is not to have feature failures due to technique. Feature failures because of a design problem are good, they tell you that you cannot acheive what you now want given how the model was built.

I've done a lot of skeleton driven TDD over the last decade.  In fact, I rarely build an assy without it anymore.  There are a lot of things to address, but I'll touch on a few.

The biggest thing you can do it build your design spec into your features.  As someone rolls through your model tree, they should be able to create a design spec for your model based on how you built it.  As you create a feature, make every reference meaningful.  This hole needs to be tied to that surface so they move together, this cut needs to maintain it's relationship to that boss, so dimension it there.  Make every reference count.

Don't be afraid to redefine features to better reflect your design intent as it changes.  I've gone into feature 5 or 6 of a skeleton that drives dozens of parts and thousands of features when the design spec changed and that was where it was defined.  If you've done a good job on the first point you can do this with minimal failures down stream.

Reroute and replace is your friend.  Rather than deleting references in the sketch or in the feature, use the replace function in sketcher and the reroute for features to maintain the references for the children.  Replace entities in sketcher is particularly powerful as it means the new entity carries the same ID as the old one and any surfaces or edges created by it carry the same IDs as well.  Downstream features then won't fail, unless there are geometry conditions that cause failure.

Don't be afraid to go all in.  There's a temptation to make your skeleton basic and only put in "critical" features.  I've found that I have better luck when I put in pretty much everything that 2 or more components share, particularly early in the process.  Near the end, the value of the skeleton is less and I'll skip adding very minor things to it the closer we get to tooling, but early on it pretty much all goes in.

in general, I've found the more that you build carefully and intentionally to reflect your design intent, the more robust and flexible your models become.  I've also found that maybe less than 25% of users really get this and use it to its full potential.

[Jacek_Mydlikows]

Hello Doug

thank you for your comment.

I follow same steps you discribed above. There is nothing I can add to this or extend.

All you wrote is true, however this is not what I was asking about.

The issue I tried to describe in my first post, was about having TDD assembly with some extra flexibility regarding handling the references.

My goal would be:

* making Publish Geometry feature more inteligent, this means it should collect the entities itself without manualy placing every new curve or quilt by the user

* making the publish geometry less sensitive to changes of entities it contains.

I am aware this appraoch won`t find a place or be reasonable for big, matured assemblies like valves, engines, and so forth, where product exists long on the marker and it is necessary to create some kind new variant of it. However for smaller products or subassemblies where content or shape is not known or under development I found such possibility very intresting to have.

[dgschaefer]

Ah, I see, sorry to go off track.

I find that using intent chains or intent surfaces when available are helpful here, but they are not always available in the configuration that you need,  I guess I just deal with the failures & changes as they come.  The reroute & replace I mentioned can help minimize downstream failures too.

I'm not familiar with the reference feature you've illustrated above, is that a bit like building your own intent groups?  I remember seeing something on that a while back, but never was able to use it.  Can you elaborate on how you've made that?

[Jacek_Mydlikows]

well reference feature solves my problem only partialy.

What it does great to me is collecting curve, edges or surfaces intent chains in single feature.

possible usage - you can create your own predefined intent edge chains, as a feature and use it in round feature

it is some kind of "in between feature" for storing in model tree desired references sets

however for TDD approach with public geometry and Creo 2 in mind, I`ve developed much more inteligent way to collect references recently.

[vzak · Accepted solution]

Hi Jasek,

Let me re phrase your goal :

- adding ALL entities of certain type to PubGeom (put it to Footer, use Move to Footer command),

- easy way to ensure all new created entities get there as well\

- ensure that when some is Deleted - your PG does nto fail (and your Copygeom does not either).

OK, here you go : use QUERIES in PubGeom collectors. e.g. :

1. To copy all surfaces : when Surfaces collector active, go Ctrl-F, set Surfaces / All / Add Query / Options / Save Query to FEATURE !

2. To copy all 3D Curves : when Chains collector active, go Ctrl-F, set 3D Curves/ All / Add Query / Options / Save Query to FEATURE . Same for Edges etc.

3. For Datums - go to References collector, do the needful.

"OK" the feature.

Now :

1. When you Delete one of collected reference - PG will not fail since reference is a kind of collection.

2. When collected references move : PG reflects it immediately.

3. When you ADD new surfaces or curves etc and want PG to get them : RMB on PubGeom, Update Query. You can make a simple mapkey for "select ALL PG features in ALL models / Update Query".

Here you go, this capability was made especially for your defined purposes. Please let me know results.

- Vlad

[Jacek_Mydlikows]

Hello Vlad

thank you very much for your reply.

This is exact solution I`ve been working on recently. I made extra test assembly to play with references forward and back and find out how the the publish geometry and copy geom could be treated to stand as much changes as possible.

First, this functionality is available in Creo 2.0 and higher versions plus it is a must to update Publish Geom every time the change in skeleton geometry is made.

There some good habbits one should consider or follow while using this funcionality:

* it is smart to establish some naming standard for group of features which are auxiliary and those which are the result we are going to share by Publish geometry(i.e making a prefix in feature name ref-sketch-no-1 or ref-surf-no-1 and so on, then searching by ref-ske* or ref-surf*), this make it easier to automaticaly collect entities we are really interested in

* in final model it is smarter to use curves from Copy Geom only as references in sketcher not as Copy curves or Use Edge, because after making the signifcant changes in skeleton model we will only be prompted to solve the references not the sketch entities instead.

[dcokin]

I'm a bit late to the party here, but thought I'd chime in as I use a totally different approach to this problem.

I eschew using Copy Geom features entirely.  Too many steps to go from a sketch in a skeleton to a solid feature in a part, and too many ways it can break when you update the sketch.  Instead, I just use the features in the skeleton part directly without ever copying them.

This does require a change to typical model hierarchies at times.  For instance, if I am creating even a simple part that I want related to the top level skeleton...  I wrap it in an assembly.  Everything that needs reference links gets an assembly.  A duplicate instance of the top level skeleton (or several skeletons) is placed in this assembly.  The part within is named identically to the assembly, or with a suffix to indicate it's subordinate.  The part is activated, and then you start making solids.  You can select sketches & datums from the skeleton, without ever having to copy them. Saves a bunch of steps, and eliminates copy geom features that can break when making changes.  You just have to get used to having these extra assembly wrappers around various simple parts.  (For more complicated parts, you'd probably need an assembly wrapper anyway, for instance to add threaded inserts, etc.)

TOP_ASSY.asm

            TOP_SKELETON.prt

            COMPONENT_1.asm

TOP_SKELETON.prt

COPONENT_1.prt

            COMPONENT_2.asm

TOP_SKELETON.prt

COPONENT_2.prt

[DonSenchuk]

I don't follow why COMPONENT_1.asm and COMPONENT_2.asm exist at all.

I get that you're activating COMPONENT_1.prt and referencing the skeleton features. I've been there. But why bother with the COMPONENT.asm? Couldn't you more easily...

TOP_ASSY.asm

            TOP_SKELETON.prt

            COMPONENT_1.prt

            COMPONENT_2.prt

... then activate the COMPONENT.prt and get your external references from the TOP_SKELETON.prt that way?

[TomU]

Just guessing here...but probably so he can work on the individual components without needing to have the top level assembly open.

[DonSenchuk]

Ah. I see. I guess I would just approach it differently.

Like use Merge/Inheritance and still retain the functionality of it updating the geometry with a simple regenerate, but without the need for the .asm. Or, like mentioned above, publishing all the skeleton geometry.

[dcokin]

As Tom guessed, I like to be able to open the components individually, but still have access to all the skeleton features.  Every part should link to its own private instance of any needed skeletons.  This also allows me to reuse parts in other places, or other assemblies, without having any issues of relational links being out of context.

Merge/Inheritance features have their place, but not for copying skeleton geometry!  This would pull everything from the skeleton into the part, and all within one feature.  Not very convenient when you want to select something specific!

Maybe I should explain how complicated I let my skeletons get.  I often use one skeleton for an entire project; at least, that's my approach when I'm the only one working on it.  I like to do this so I don't have to worry about figuring out parent-child relationships in advance; I can just start with the most obvious features, and let the design evolve.  Example: start by sketching a plate.  Locate bracket on the edge of plate.  Later... I may realize I actually have to put that bracket in a specific position, and the edge of the plate should be dependent on that, not vice versa. If these features were in different parts, editing this would be a pain, and I would be at risk of generating circular references in the process.  But with it all in the same skeleton, I can just delete a reference from the bracket sketch, drag it up the tree so it's above the plate sketch, and then edit the plate sketch to reference the bracket sketch.  A lot harder to invert parent/child relationships if they're not in the same file.

These skeletons can become pretty large, but they're not unwieldy, as I use a rigorous approach to layering to make them easily manageable.  Off topic for this thread, but briefly:  rules auto-layer elements by type (individual points, curves, planes, etc).  These layer names start with 0's, so are at the top of the model tree.  Features (sketches, etc) are only layered manually, by related component or system, and get higher numbers, so appear at the end of the tree.  Features related to more than one system get put on multiple layers.  For instance, continuing my example from above; I may have a sketch of points, to show the hole pattern where the plate and the bracket attach.  This sketch will be added to a layer for plate, and layer for the bracket.  You must isolate at least one layer from each section to see anything.  If you isolate all the "0" layers, plus the plate layer, you'll see everything related to the plate, and nothing else.  You can also just show the points related to the bracket, etc, by isolating just the "points" layer and "bracket" layers. Skeletons with huge amounts of wireframe geometry become really easy to manage this way.

If the project matures, and I need to bring on help, then something has to change.  You can't have two people editing the same skeleton obviously.  One skeleton per person seems about the right ratio.  So this approach with just one skeleton is really just for the early conceptual phase of large projects.  But the new guy doesn't have to start over; you can carve out a subset of the skeleton to hand over responsibility.  Assuming you're working in PDMLink (and have "let_proe_rename_pdm_objects yes" in your config.pro), you load the models you want to hand off (only!) into memory and rename the skeleton.  It's only renamed in session memory; original model is still in workspace. But when you save, a new skeleton is created, and all those models that were in memory are now linked to the duplicate. You can clean out features unrelated to the new guy's assignment, and he can take it over from there.  (Note, if you're not using PDMLink, that rename command will actually rename the original file, so you'd have to create a duplicate in windows and restore the file name, so you don't break links in the models that weren't in memory, that aren't being handed off.)

[DonSenchuk]

Doesn't putting the entire top_skeleton.prt into the component_1.asm pull everything from the skeleton? Anyway, no worries. To each their own. It was curiosity on my part.

Merge/Inheritance features have their place, but not for copying skeleton geometry!  This would pull everything from the skeleton into the part, and all within one feature.  Not very convenient when you want to select something specific!

[dcokin]

Skeletons parts are layered in the assemblies (automatically, by rule).  This is the only type of part I allow to be layered by the way; visibility of other parts & assemblies is always by Simp Rep, not layers.

So, yes, the whole entire skeleton is there, but it's hidden when not being actively used. And even when it's shown, only some of it is shown, as the layers within are adjusted.

By the way, I'd advocate everyone put "floating_layer_tree yes" in their config.pro.  Without this, the layer tree obscures the model tree, which makes it a lot harder to click between them!  (The layer tree has a cursor button, that lets you select another model to show the layers of.  So, for instance, you can adjust skeleton layers even if that's not your active model.)