Multi-body or Assembly?

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.

JKimmel wrote:

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 someth> Matt,

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.

1. 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.

1. 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.

1. 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.