Gabi Jack's Blog: The "Body" System (part I)

As I mentioned in a previous post, I’ve spent some time learning about the use of multibodies in SolidWorks. It’s a fascinating subject, indeed! I had used multibodies before, when modeling the hairclip, but mostly I had limited myself to combining two or more bodies into one. Now, I’m learning to do the opposite: create two or more separate bodies out of one, and save them as individual files.

In SolidWorks, one body can be separated into two or more by many different ways: an extruded cut, a revolve cut, cutting with a surface, etc. It is also possible to use the Split command to divide the body into smaller parts. Why use multibodies? Well, I guess you may want to take a look at what Matt Lombard had to say about it in his presentation “The Care and Feeding of Multibodies in SolidWorks”. He gives a very thorough explanation of why and why not use multibodies when designing with SolidWorks.

As an exercise in creating multibodies, I decided to try and reproduce one of my son’s Cooties, a little bug looking toy. So, first, I modeled the shape of the body as a single solid using the loft feature and a few circular profiles. I named this part Buggy.

Then, I divided the part into two new ones by using the Split command (Insert, Features, Split). In this case, the Right plane served as a trim tool, but it could also be a surface. After selecting my trim tool and clicking Cut Part, the body is divided in two and I’m given the choice to save the resulting bodies as two individual parts, which I named BuggyRight.sldprt and Buggyleft.sldprt.

Notice the Split feature that is added to the feature manager in the Buggy part. There’s also a reference to the Buggy part in each one of the two new parts created this way.

This means that the two new parts created are still connected and dependent on the first one, Buggy. I tried opening Buggyleft on its own, and notice how the reference to Buggy appeared to be out of context, but the file still opens and rebuilds. It will always appear out of context if the parent file isn't open at the same time.

The same happens if I move the file to a different directory or if I rename the file. When reloading Buggyleft.sldprt after renaming Buggy.sldprt to something else, first I got the following message. I chose not to look for the file, and Buggyleft.sldprt still reloaded, only with an out of context reference to Buggy.sldprt.

So, up to this point it seems like the worse that can happen if you misplace the parent file is to have some out of context references. The changes you apply to any of the new parts don’t affect the parent file, Buggy.sldprt, so you won’t be needing to update that file, like you would with an assembly. However, if you make any changes to the parent file, Buggy.sldprt, BEFORE the Split feature, they will reflect on the two new parts, and any changes you make to the Split feature itself can and will affect the parts that were created by that Split feature. I realized this when I chose the Top plane as a trim tool by mistake. I created two parts this way: Buggybottom.sldprt and Buggytop.sldprt. When I realized that I needed to split the body using the Right plane instead, I went back to Buggy.sldprt and edited the Split feature, thus creating another set of files: Buggyleft.sldprt and Buggyright.sldprt. After creating the second set of files, however, I went back to Buggytop.sldprt and look what happened to it.

Hovering my cursor over the Split feature in the feature manager I get a message that says that the Split is not valid. The funny thing is, this happens only as long as Buggy.sldprt can be located. If I change the name of the file or get rid of it some other way, then Buggytop.sldprt will reload with out of context reference to Buggy.sldprt. I could break the references and then I’ll be able to load the part, it won’t be dependent of Buggy.sldprt anymore, although the evidence of reference will continue to be part of the file and the feature manager (notice the x next to the reference), indicating that the reference is broken now. Interesting, isn’t it?