Soliciting opinions on Pubs and ECG methodology abuse/overuse

[DeanLong]

In the good old dayswhen TDDwas still in diapers, we used copy geom's with reference, merges with reference etc... to create our models and assemblies. We used them as the exception to the rule, opting to keep as much of the model definition (Geometry)in one place. Also,when Skeletons came about it was nice to have a lightweight "driver model" that could propagate intent to multiple models all the while not showing up in the BOM's. They were/are very useful and serve a great purpose to this day.

NOW....with the arrival of Pubs and ECG's on the scene many of the "quirks" and uncertainty of the old methods were pretty much put to bed. My philosopy using such anmodeling, whether old merges or new Pubs and ECG's, has always been"Keep it Simple and Lightweight". However, I seemore and morecases these daysof "too much power used" when it comes to modeling creation. I see such convoluted, multiple Pub, ECG and skels, created outside a particular model, then copied in, referenced, merged and solidified, that the part geometry essentially does not "exist" until all the external info is brought in and processed.

Has this become the new "standard" of modeling and design? I find the need to make a change on Part A requiring me to open four skels, update 13 Pubs and subsequent ECG's....well...silly, unneccessary, abuse of power, counter-productive...stop me at any time. I spend more time checking and rechecking my ECG's are active and regenerated, pulling huge skeletons filled with curves and surfaces,redefiningPubs and then verifying it all regenerates in my "part" that it becomesreally frustrating.Just because we can...should we?

Where areyou guys on this?

thanks...

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dgschaefer]

I've seen some pretty convoluted implementations of copy and publish
geometries. There seems to be a thinking at times of "Oh look, the
geometry that I need is over there. I'll just grab it and then it'll
all update magically!"



I use a pretty involved method for my TDD assemblies because I feel that
TDD works best when fully implemented. IN other words, if two parts
share some kind of geometry, it should be skeleton driven. However, I
follow a few simple rules to keep it manageable.



* Publish geometries should only reside in the skeleton, never in
parts
* There should typically only be one PG / CG pair per part.
* Always copy down (skeleton to components) never 'sideways'
(component to component) or 'up' (component to skeleton)
* Each sub assy should have its own skeleton. Exceptions for sub
assy's that really act like parts like a plastic part with molded in
inserts or a sheetmetal part with PEM fasteners.
* Put skeleton geometry only as high up in the assy structure as
required. For example, an axis controlling screw alignment between two
parts in a sub assy should only be in the sub assy skeleton, not the top
level skeleton.
* Never skip levels with a PG / CG pair. In other words, don't
pass from the top level skeleton to a sub-sub-assy skeleton.
* Use a dedicated CS for ECGs so you know where it's located. I
typically use standard CG to avoid the potential misalignment of the
ECG, but when you need motion in your assembly or if the part isn't
unique to that assy, an ECG makes more sense.



Of course, there are exception to those rules, but this is the general
method I follow and it helps to create logical path for the geometry and
makes it easier to find what's driving what.



Doug Schaefer

[DeanLong]

Yeah Doug...I am tracking you. All that you wrote is where I live as well.

I see so many "Look Ma, no hands!" scenarios when it comes to walking the Pro/E tightrope in many companies. Some get away with it, others not so. In many cases, I find as the outsider, I can see the forest where they see the trees. The things they do arejust the things they do...the machine runs, it becomes a maintenence issue and then don't rock the boat.

[mpeterson]

Once I learned the Master Modeling technique I have used it in the development
of a variety of products and it has served me well. Doug points out some of the
main concepts associated with this method to keep it as simple as possible yet
get the most bang for the buck out of Pro/E and control the design intent. Just
yesterday I put together some information for a coworker to show him the general
theory behind this method.

Yes, Published Geometry and Copy Geometry can be used too easily and without
much thought as to changing things down the road or others having to pick up
your model and make changes. Thus the reason to develop and follow some
guidelines and concepts in PLANNING out the design and thus the Top Down Design
approach.

I think there are too many who just dive into a design and start carving and
whittling geometry without thinking about where the design intent is going
and/or how and where things might change later. In my opinion it is well worth
it to give some thought to the what is important to the design and how to
organize it up front. It will pay off in the end when the design iterations and
changes happen. For those who worked on the board many years ago it is really
the same as a the main layout of a design where critical dimension, shapes,
clearances, etc are drawn that others use in their particular part or sub
assembly design. I do realize that some products or projects are pretty loosely
defined up front and one must create some parts and assemblies to get an idea
where the direction of the design should go, but once a general direction is set
then time to start setting up a Master Model or driving skeleton model to drive
the design and downstream models.

I highly recommend using the Master Model/Top Down Design methods AND the rules
that Doug listed.

"Practice Safe Design - Use a Concept"


Mark A. Peterson
Sr Design Engineer
Igloo Products Corp
-

[BrentDrysdale]

Hi Dean and Doug,
Yes pretty much as Doug says for us BUT we do some things differently which
suit our case. I have copied Doug's points below and added comments.


- Publish geometries should only reside in the skeleton, never in parts
- There should typically only be one PG / CG pair per part. [BD; Agreed]
- Always copy down (skeleton to components) never ‘sideways’ (component
to component) or ‘up’ (component to skeleton) [BD; Agreed]
- Each sub assy should have its own skeleton. Exceptions for sub assy’s
that really act like parts like a plastic part with molded in inserts or a
sheetmetal part with PEM fasteners. [BD; Yes and no. We only make a sub
assembly Skeleton if there are interfaces between parts in that sub-assembly
that need defining and these do not better lay further up the tree.]
- Put skeleton geometry only as high up in the assy structure as
required. For example, an axis controlling screw alignment between two
parts in a sub assy should only be in the sub assy skeleton, not the top
level skeleton. [BD; I see the logic in this but for our products we do
not have many levels of sub assemblies so have always used the top level
Skeleton]
- Never skip levels with a PG / CG pair. In other words, don’t pass from
the top level skeleton to a sub-sub-assy skeleton. [BD; We used to
follow this but not now. We found the overhead of maintaining these even
during the design phase was not for us but we were making Copy Geoms in the
sub assembly of the higher level Pub Geoms so that the sub assembly carried
all info; too hard and saw no real added value. We do Publish Geom at the
top level and jump one or two or even three levels down to parts. We always
know where to look for interface information. I could see however that in
much larger assemblies with many levels then your approach is good.]
- Use a dedicated CS for ECGs so you know where it’s located. I
typically use standard CG to avoid the potential misalignment of the ECG,
but when you need motion in your assembly or if the part isn’t unique to
that assy, an ECG makes more sense. [BD; Do not use ECGs. Lack of trust
from some made in assemblies early last decade. For our purposes CG is
great. i can see what you mean for Motion though but we do not really do
much Motion work.]

Added to this is that our Skeleton is usually quite complex with several
hundred features (Surfaces and Datum features only) and will have dozens of
Pub Geoms for various uses. Works very robustly for us.

Regards, Brent Drysdale
Senior Mechanical Designer
Tait Radio Communications
New Zealand
DDI +64 3 358 1093
www.taitradio.com

[HugoHermans]

I added some comments as well.

Met vriendelijke groeten, Hugo.

NV Michel Van de Wiele
Carpet and Velvet weaving machines
M. Vandewielestraat 7
8510 Marke, Belgium

[DeanLong]

Pub Geoms for various uses. Works very robustly for us."" Brent

Brent,

While I understand there are no rules with the use of skel's I think the fact that you have "hundreds of features" in a skel somewhat negates the spirit of the skeleton. If you go to that much effort for a mere skeleton, it seems as though you might as well just model all of it in one part. I can see the need for multiple skels for large, multi-assembly products (Planes, Trains and Automobiles) where "zones" of concurrent engineering are taking place. Maybe you have that scenario.

I just recall the "selling" of the skel philosophy back in the day as "lightweight, basic and minimalistic". Now...all bets are off. Skels are becoming as complex as the parts they are driving. Actually, they can be more difficult to work with at times because it has curves, points and surfaces that are more difficult to manage than solids.

I know all this is subjective and everyone gets on with their particular Hop, Skip and Jump. I was merely curious what was happening out there.

Dean

[BrentDrysdale]

Hi Dean,
Ah ha! This is where we have differences of opinion.

I do stress that the way we uses Skeletons is very robust for us but that it
may not be applicable to other types of design. We see our use as really
tapping the power of Skeletons. Unlike some companies we are much more
interested in the 3D models for direct use in toolmaking and our drawings
are usually fairly minimal. We don't even think about Shown Dims most of
the time as the geometry does not suit this approach except for more basic
features.

The best way I can explain is that we use Skeleton functionality to replace
the older concept of Master Modelling i.e. the Skeleton itself has the form
of the whole unit and these are typically multiple curved shapes. We make
Pub Geoms of selections of those surfaces to Copy Geom into the parts and
construct from there. We use this early in the design cycle once the
Concept is approved and where changes are required the skeleton is modified
and the changes propagated through the assembly.

Once again; this is our method of using ProE and it may not suit many.


Regards, Brent Drysdale
Senior Mechanical Designer
Tait Radio Communications
New Zealand
DDI +64 3 358 1093
www.taitradio.com

[dgschaefer]

The way I prefer to use skeletons modeling is to represent everything
that 2 or more parts share in a skeleton at some level of the assy. I
don't try to determine if the shared geometry is critical or important
enough to go in the skeleton, I simply put everything in there if two
parts share it. It is not uncommon to have a top level skeleton of 100
features or more along with sub assy skeletons with a couple of dozen
features each.



In doing so, I'm capturing my design intent for the entire product
within the skeleton. I don't have to think about if a change is needed
at the skeleton level or if I have to track down each of the effected
parts and modify them individually because that particular feature
didn't make the cut for inclusion in the skeleton. Does it get complex?
Yes, but that complexity is working for me by keeping track of those
inter-part relationships and managing for me so I don't have to.



I really only think through that complexity once, when it's created.
When I need to modify it, I may have to look through the feature
relationships to refresh my memory as to what's going on, but that's
easier because the assy provides a road map as to how those complex
relationships work. Really, the products are complex, having complexity
in the models simple reflects that.



Doug Schaefer

[DeanLong]

Yeah Brent...no doubtmany get on with the useability that suits the purpose just fine. I guess the fulcrumI stand upon in posing this threadis "when is too much...well, too much?" I know that question is hugely subjective.

I am an advocate, and daily user, of TDD. I thinksome/many balance and managethe power of TDD vs. the potential unruly Skels/PG's/ECG's quite well,while others get caught in the euphoria of the"coolness" of magically building a part "over there" from "over here" and find themselves fighting the skels more than the parts.

I guess discretion always has an impact.

Thanks for playing along.

[ptc-593619]

Of course this doesn't begin to answer the question as to whether "TDD"
is better/worse than "BUD"! As a team of one, the latter seems to me to
be a better approach, depends on the "design", I guess.

BTW "bud" always appeals on a Friday evening.