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?
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.
Pub Geoms for various uses. Works very robustly for us."" 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.
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.