Multi-body or Assembly?

Is there anyone else out there making extensive use of multi-body
modeling, not counting weldments?

For example: I will typically make a sheet metal stamped part plus the
die over which the part is formed as a single multibody part. (These
are one-off parts, not production tooling). I also frequently model
simple assemblies as multibody parts which I then split and either
reassemble into an assembly, or just add features to individual parts,
which often means converting them to sheet metal parts.

I used to do these tasks in the traditional way, but after watching a
multi-body demonstration at a user group meeting, I tried it out myself
and it seemed to solve a lot of problems that I've had (and continue to
have) with assemblies: disappearing external references, moving or
renaming parts, changing computer or server configurations. My
experience is that it's a much faster and more robust method of modeling
small assemblies than the traditional way. I don't use Solidworks BOM
or a PDM (yet), and I still do a lot of traditional assembly modeling.

The Solidworks Establishment seems to be very much opposed to this
method and I'm coming under a lot of pressure to stop, mainly from
people with little or no Solidworks experience. Any arguments for me
either way?

Thanks,
--
John Kimmel

www.metalinnovations.com

"Cuius testiculos habes, habeas cardia et cerebellum." - When you have
their full attention in your grip, their hearts and minds will follow.

 

It all depends on how you do this. There can be glitches with the split
part feature but there are also ways around that are robust. Who is the
SW "Establishment"?

 

TOP wrote:
Who is the

A VAR representative and a Community College Solidworks instructor.

 

There are a few things that you cannot do when you model all of the
parts in an assembly as bodies in a single part:

- interference detection
- dynamic motion
- auto BOM population
- exploded views
- display states
- you cannot mix sheet metal with other types of parts

There are also some things that become seriously hampered by modeling
this way:

- troubleshooting
- isolating the features and geometry of a single part
- for more than a few parts your rebuild speed is going to take a
serious hit
- moving parts becomes a major pain
- getting data to manufacturing can be a problem depending on how you do
things
- making drawings can be a bit of a pain
- using custom properties for parts becomes a problem
- managing visibility of bodies or keeping bodies that are separate from
merging are both going to cause you some headaches

I'm sure there is a long list of other things I am missing here.

In contrast, the advantages are that it simplifies file management, and
that external references are simplified (essentially the file management
issue again).

Multibody modeling is like in-context in that you should avoid doing a
lot of it.

Purists may call this a technique for excitable beginners which you will
out-grow after a while. If you do anything with more than a few parts in
it, the multibody approach becomes unmanageable quickly.

I don't believe anyone will tell you that it technically can't be done,
just that it's a bad idea even though aspects of it look attractive. UG,
Mechanical Desktop and AutoCAD R10 AME use that approach.

 

VARs don't necessarily speak ex-cathedra on these matters nor do
Community College instructors. What they should be doing is showing
you when and where and what limitations there are on any given method
and not dismissing it outright. They may be raising a flag which you
would do well to investigate, but you still have to look at the quality
of the source and the use for the technique. There is a lot of
variation between VARS and even at a particular VAR there may be
several opinions prevalent. "Established" opinions can be wrong. I've
had my share, many times due to the fact that SW changes with time.

 

Matt,

You forgot mass caculations, FEA, Mold flow, CG, the list goes on and on

Mark

 

Matt,

I think he knows what the limitations are. He has stated that he uses
this in a limited way for quick and dirty. BTW you can do a limited
form of interference detection in Multibody in that if you try to
combine two bodies using intersection and there is no interference the
combine won't result in anything. Since he is exporting to an assembly
he can still do a lot of the stuff on your list once he puts them in a
real assembly.

Also in a multibody you can use the delete body feature to get rid of
the extraneous bodies for mass props.

It sounds like he is into stamped parts and of course the other good
use of multibody there is to get the waste material.

As John described it he is primarily using a master model approach and
he is using split body to get the bodies out and into a real assembly.
As far as his use with the die and part design that makes a lot more
sense than using incontext or cavity through an assembly IMHO.

 

I agree that the tooling makes more sense than just modeling general
assemblies as a single multibody part, although I'm still not a big fan
of it.

SW does the Mold Tools as multibody, which has pluses and minuses. Split
Works does the same thing as an assembly, which I think works better. I
really don't like jumbling the features of multiple parts in a single
feature tree. That makes SW far more difficult to use, and the
performance overhead of putting everything into one pile, as well as
reuse issues... If you like to use Insert Model Items in drawings, all
of that data is lost if you do multibody and break into an assembly.
Plus, I don't think the arguments against assemblies are very
compelling. Also, any of the best practice part modeling stuff regarding
planes, the origin, symmetry is thrown out the window when modeling an
assembly as a part.

I do plenty of multibody work, and am more than a little disenchanted
with it. There are certainly times when it is appropriate, but I find
myself doing it grudgingly now. I've had it happen that if a feature
accidentally doesn't get the Merge switch flipped off, unexpected
parent/child relations can be created due to SW automatically merging
planar/cylindrical faces. This can make editing very difficult.

A project I did last year was a very complex shopping cart basket. It
was started as a single part master model with all of the major faces
built as surfaces, and this original part was then inserted into 3 other
parts (representing areas formed by separate sections of tooling) which
were built individually from the master model as separate parts having
approx 300, 400 and 600 features respectively, and then brought back
together as a single part using Insert Part. This was done so that I
didn't have a single part with 1300 features in it. The performance was
still slow, but not nearly as slow as it would have been.

This is really the reverse technique of modeling an assembly as a part.

Then of course are all of the problems discussed at length here in the
ng regarding the Split, Save Bodies, Insert Part, Insert Into New Part
functions which are nowhere near being reliable enough to base a whole
method for modeling on. I recommend against going too far down the
multibody route and finding some bug or limitation that puts the brakes
on your whole operation.

Obviously, John can do what he likes, but to me the multibody method is
something that looks good on the surface, but under that it falls apart
rather quickly for real work.

 

I do use multibodies in a single part to model separate components ...
judiciously.

For instance, I am working on a make-or-break project for a new company
right now, and because of the schedule and budget I concluded that I
could not ethically or responsibly consider working this project any
other way.

Here are the rules that I use to decide whether to do
master-model/multi-body based on its impact to the delivery time and
overall editability/flexibility/usefulness of the dataset.

1. I only model multiple components in a single part when those
components are so intimately intertwined that in-context is a terribly
complicated or unworkable option.

Two metal plates that relate to one another? (or other simple shapes,
like the elements of the wood furniture I've been working on for
myself) - go in-context.

Components of a more elaborate product that, on analysis, still have
only a few relations to each other? - go in-context.

Multiple components of a molded or cast product that require dozens
(and dozens and dozens...) of relations to each other - multi-body.
On my current project, I am using a mix. Some in-context, some
master-model. It depends on the component and where I feel its best to
have the features that make it.

2. Use multi-bodies if the relations are handled best with a sense of
'history'. In-context refs are always to the final state of the
referenced model after it has been rebuilt.

Most folks with experience know to make in-context refs to things that
can't be changed by subsequent features - sketches and planes (we
learn that edges and faces can be fouled by fillets, split lines,
drafts, etc) But sometimes its such a spiders web of stuff that its
best to deal with refs via a linear feature tree that you can
absolutely and intuitively control, which is what multi-body master
models affords you.

3. Use 'Master model' only until the refs between components are
established, then finish the parts in the offspring.

I want to keep the rebuild time of the master model as short as
possible - its too much stupid overhead to have all the drafts,
fillets, etc. required to finish components in the master model because
then all the other components also have to rebuild it (then discard
it!) to find out what they look like.

I also have engineers who want dims in models so they can work with
them and ultimately insert them into the drawing. Dims from the master
model don't transfer to the child parts - dims in the child parts
are there for everyone to use. I put as many CTF (critical to
function) dims into the child parts as possible so they are available
for the engineers/drawing.

4. I may be tempted to do a fast, down-and-dirty assembly as a master
model instead just to get a concept out. Heck, if we are presenting a
concept, there is a really good chance it will change as we develop it,
and an excellent chance that it will be discarded altogether (if we
present five concepts and they pick on, that's an 80% rejection rate)
But even so, if I suspect it might go further, I will be careful and
start to apply the above rules. That's a decision made from
job-to-job based on economics, experience, hunches, a little voodoo,
etc. And, of course, I have learned from experience that if it goes to
the next level, it saves time and money to rebuild stuff in separate
part files * that really needs to be in separate part files * instead
of trying to keep the master model when it is not consistent with the
above rules (pennywise/pound-foolish).

and... oh, I bet I missed a few other good rules.

Ed

Post script:
It was odd to hear you say that the SWx establishment is opposed to
multi-body modeling. I thought that the establishment was moving
towards multi-body modeling - there are multiple, distinct ways of
doing it (if it wasn't supported, they wouldn't' keep coming up
with ways to pass bodies onto new parts, like split, RMB save body to
new part, insert part, etc) there are features/modeling techniques like
'weldments' that rely on it, and at SWx word I've seen sessions
by SWx employees that unapologetically demonstrate it. Thanks for
clarifying that it was your VAR and community college instructor. In
Concord, I know that it is considered to be a very important part of
SWx.

It would be good if those folks gave you the context for their opinions
or let you know what informed their opinions. There are a lot of
really good reasons not to use it - its 'seeming' convenience is
not justification.

1. There are important stability/recoverability issues.
Hint-use insert part to make your child parts < used to be called
insert base part> because it is always recoverable (though you can use
anything if you are really clever and dedicated, like matt, who can
make anything work.) Split part where you save bodies out has a lot of
KNOWN PROBLEMS (hint), same with RMB save body to new part. Example -
I had a client in last week whose file had gone FUBAR because of that
last one, and we had to use 'insert part' in the child part to save
it.
2. There is a big file-management negative (how does a file
management system deal with a part model that doesn't actually get a
part number, because it is the parent of a number of other parts? Boy,
I have run into issues about that with customers)
3. There is an education/responsibility issue. If you work with
someone who isn't familiar with it, they can easily (and innocently)
screw everything up.
4. There is an overhead issue - if the assembly is initially
modeled in a single part, each component essentially carries the
rebuild time of all of the other parts of the assembly (again,
depending on how you do it)
5. Then there is lots of stuff that matt mentioned - drawings
being a big one, sheetmetal being one I don't recall being mentioned
(no multi-bodies in sheetmetal). I could go on at length. (and did, to
some extent, at last SWx world - files on our site)

If someone tells you not to do something, I would hope they would also
take the time to tell you why.

 

Useful tip on VERY involved parts.

Thought experiment:
We use subassemblies to make our assemblies manageable and don't bat an
eyelash about it.
There are times when judicious use of 'sub-parts' to make a complete
part makes the final part creation manageable.

Back in SWx 99, I had a part with three distinct zones. I made a
master model, used insert-base-part to create three parts representing
each zone, added detail in those sub-parts, then used 'join' to bring
them all together. There was just no other way to do it efficiently
(and economically - its all about money) at that time with the
available processing power.

I haven't needed to do that in a while, but in cases like matt's, it
makes sense and its good to have in your bag of tricks.

The important thing is that though the performance might still be slow
when bringing them all together, the performance when working/designing
any individual chunk of the product might be a ton faster.
Hopefully, most of your time is spent designing and trying out design
iterations - this is a way to maximize your productivity during what
you focus your day on.

BTW - only experience/hunches/a little voodoo will inform what is the
right approach. But if you are sitting waiting five-ten minutes for a
part to rebuild, it becomes a little more obvious.
ED

 

Thanks for all the responses. My local user group is going to get Jack
Sanford's SWW presentation on "master model techniques" on Dec 2nd.
--
J Kimmel

www.metalinnovations.com

"Cuius testiculos habes, habeas cardia et cerebellum." - When you have
their full attention in your grip, their hearts and minds will follow.